Re: [MIPS] New socket constants

[Matt Turner <mattst88 at gmail dot com>]

On Tue, Jan 25, 2011 at 8:50 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> I've applied this patch to define new bits/socket.h constants for MIPS, in
> line with the libc version. ?Alpha and PA maintainers may wish to make
> similar changes to their versions of this header.
>
> diff --git a/ChangeLog.mips b/ChangeLog.mips
> index 0d933f3..16ca191 100644
> --- a/ChangeLog.mips
> +++ b/ChangeLog.mips
> @@ -1,3 +1,8 @@
> +2011-01-25 ?Joseph Myers ?<joseph@codesourcery.com>
> +
> + ? ? ? * sysdeps/unix/sysv/linux/mips/bits/socket.h (AF_CAIF, AF_ALG,
> + ? ? ? PF_CAIF, PF_ALG): Define.
> +
> ?2010-12-30 ?Joseph Myers ?<joseph@codesourcery.com>
>
> ? ? ? ?* sysdeps/mips/init-first.c: Don't call __libc_global_ctors if
> diff --git a/sysdeps/unix/sysv/linux/mips/bits/socket.h b/sysdeps/unix/sysv/linux/mips/bits/socket.h
> index 9f90216..91af8b2 100644
> --- a/sysdeps/unix/sysv/linux/mips/bits/socket.h
> +++ b/sysdeps/unix/sysv/linux/mips/bits/socket.h
> @@ -1,6 +1,6 @@
> ?/* System-specific socket constants and types. ?Linux/MIPS version.
> ? ?Copyright (C) 1991, 92, 1994-1999, 2000, 2001, 2004, 2005, 2006, 2007, 2008,
> - ? 2009, 2010 Free Software Foundation, Inc.
> + ? 2009, 2010, 2011 Free Software Foundation, Inc.
> ? ?This file is part of the GNU C Library.
>
> ? ?The GNU C Library is free software; you can redistribute it and/or
> @@ -109,7 +109,9 @@ enum __socket_type
> ?#define PF_ISDN ? ? ? ? ? ? ? ?34 ? ? ?/* mISDN sockets. ?*/
> ?#define PF_PHONET ? ? ?35 ? ? ?/* Phonet sockets. ?*/
> ?#define PF_IEEE802154 ?36 ? ? ?/* IEEE 802.15.4 sockets. ?*/
> -#define ? ? ? ?PF_MAX ? ? ? ? ?37 ? ? ?/* For now.. ?*/
> +#define PF_CAIF ? ? ? ? ? ? ? ?37 ? ? ?/* CAIF sockets. ?*/
> +#define PF_ALG ? ? ? ? 38 ? ? ?/* Algorithm sockets. ?*/
> +#define ? ? ? ?PF_MAX ? ? ? ? ?39 ? ? ?/* For now.. ?*/
>
> ?/* Address families. ?*/
> ?#define ? ? ? ?AF_UNSPEC ? ? ? PF_UNSPEC
> @@ -150,6 +152,8 @@ enum __socket_type
> ?#define AF_ISDN ? ? ? ? ? ? ? ?PF_ISDN
> ?#define AF_PHONET ? ? ?PF_PHONET
> ?#define AF_IEEE802154 ?PF_IEEE802154
> +#define AF_CAIF ? ? ? ? ? ? ? ?PF_CAIF
> +#define AF_ALG ? ? ? ? PF_ALG
> ?#define ? ? ? ?AF_MAX ? ? ? ? ?PF_MAX
>
> ?/* Socket level values. ?Others are defined in the appropriate headers.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

<the follow is not directed at you, Joseph>

Sigh. Can't we split architecture-specific definitions out into bits/
files or something? I'm sure you know how silly it is to duplicate
these things in eight different places.

Guy Martin sent patches to do this a few months ago, and list members'
responses where:

Carlos O'Donnell:
"""
The patches decreases maintenance cost for the targets, avoiding
duplication of all of the header files for each target.
"""

Joseph S. Myers:
"""
The fact that the SPARC versions of sys/inotify.h, sys/epoll.h and
sys/eventfd.h are out of sync with the generic Linux versions shows quite
clearly that something should be changed, as updates to the SPARC versions
of these files - in libc, not ports - are being missed when the generic
versions are updated, so the present system for maintaining these files is
not in fact working.

I suggest that the reason it is not working is that the presence of
multiple copies of these sys/* files violates the expectation that only
bits/* files require versions for multiple target architectures to be
updated - the prototypes and architecture-independent definitions should
be in the present sys/* headers, but the _CLOEXEC and _NONBLOCK values
should be in bits/* headers, and only the bits/* headers would be
duplicated for multiple targets, so making it much more obvious which
changes require target headers to be updated.
"""

It seems like Guy identified a problem and worked with glibc
maintainers to come to a sensible solution, and that the only reason
it wasn't actually included was Ulrich, and his arguments against it
were...

Ulrich Drepper:
"""
Get those ignorant kernel arch maintainers to use the same values as
the mainstream architectures.

I'm not making compiling slower just because of these crappy
architectures with maintainers who cannot think straight.
"""

So ignoring the inflammatory text, (1) change the kernel, not glibc;
(2) this patch would slow compilation down.

(1) simply isn't possible since it would break the kernel's ABI. This
is not reasonable.
(2) I've got to think this is entirely bullshit. How long do typical
glibc compilations take? 10 minutes on a modern system? Even at that,
a massive amount of time is spent with glibc's crazy makefile system.
If anyone would care about compile time it'd be the people maintaining
these ports for older systems.

And if we care about time, let's consider the amount of time it takes
to make these changes to each ports' set of headers. I think that
measure of time is a bit more important than compile time. Or, the
amount of time we spend tracking down small typos in these headers
that cause big headaches. Alpha and HPPA have both had their share of
these kinds of problems.

So really, can't we actually fix this?

Matt