On Friday 11 January 2008, H. Peter Anvin wrote: > Mike Frysinger wrote: > >> all this stuff is ABI constants, and the only reason glibc > >> doesn't use them is that glibc prefers to use enums over #defines. > > > > a proper libc defines things in their headers according to the POSIX > > specs rather than relying on others to do it for them. if you want to > > argue about linux-specific ABI pieces being exported, then you probably > > have a valid point, but socket.h is hardly that. > > Have you looked at it?!!? It's full of ABI constants, and that's what I > care about. POSIX doesn't define, say, AF_UNIX; that's an ABI specific.
i guess it depends on how you define "define" :P. no, POSIX does not state the specific numerical value (ABI) for the define (API), but POSIX does require sys/socket.h provide the macro AF_UNIX. > > so if the only consumer is klibc and you're against adding these things > > to it, special case it for __KLIBC__. > > No, let's split the header so that there are *no* libc knowledge in the > kernel. For the kernel to have knowledge about the specifics of any > particular libc (klibc, glibc, or any other) is stupid, and that's the > whole reason we're in this spot to begin with. we're in this spot at the moment to appease klibc only. is there any other libc out there that is not providing its own complete sys/socket.h but instead relying on linux/socket.h ? glibc/uClibc rely on linux/socket.h only for the kernel's definition of sockaddr. > Again, I don't particularly care about what they're named, but the whole > point is > > #include <linux/foo.h> > > if you want the subset and > > #include <linux/bar.h> > > if you want the whole set. i looked more at glibc/uClibc and my primary/original concern (and what i thought what David was raising and you confirming) was that building of glibc was broken and glibc headers would need updates. that does not seem to be the case. the breakage here is for packages that include both sys/socket.h (directly/indirectly) and linux/socket.h (directly/indirectly). due to the way the network headers depend on each other, this case is trivial to induce. but i dont think linux/socket.h is any more special than the current retarded conflicts we have between the network headers from the libc (which are required by POSIX and beyond) and the kernel headers. > No libc specifics, and no feature test macros, which I think we can both > agree are uglier than hell. i think in general, all of the network related headers under linux/ are fubared for userspace. > I thought the naming worked out nicer with <linux/sockaddr.h> placing the sockaddr definitions into linux/sockaddr.h makes sense. -mike
signature.asc
Description: This is a digitally signed message part.
