On Friday 11 January 2008, H. Peter Anvin wrote: > Mike Frysinger wrote: > > oh, sorry, i see what you mean. i was thinking in terms of crap removed > > (as that's what i'm after), not crap added (which is what Peter is > > after). i hadnt noticed that. i dont know if it'll break glibc (and > > really, any other sane libc). if that is the case, then i think klibc > > here is the 2nd class citizen to everyone else. > > I don't really understand why you insist on using such inflammatory > language;
it's true. it is much easier to adapt klibc on the fly than every one else. klibc is also of significant less importance in the larger open source landscape than glibc or other libc's. this isnt really inflammatory so much as fact. > 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. imo klibc is being lazy. you disagree. here we are. > Right now, glibc is special-cased. glibc also tends to be very > deliberate about its kernel header inclusions. It wants a subset of the > available defines, so it can include a subset header. > > The reverse is definitely possible too -- all other users (kernel, > newlib, dietlibc, uclibc, and klibc) can change and leave the current > state for glibc. that list is inaccurate. newlib is generally not used under linux, but of the few headers it does use, socket.h is not one of them. i dont use dietlibc myself as ive found it generally not suitable for much, but a quick look through their source code shows linux/socket.h not in use at all. uClibc is the exact reason i started this thread in the first place. we have __GLIBC__ define in place to account for broken code and it's because of things like linux/socket.h that we cannot yet remove it. glibc has not used the typedefs/defines in question in ages, so they're not affected by the things not being available. that leaves klibc. > We can special-case the kernel in the above case, but that would involve > some additional ugliness. so if the only consumer is klibc and you're against adding these things to it, special case it for __KLIBC__. -mike
signature.asc
Description: This is a digitally signed message part.
