On Friday 11 January 2008, Mike Frysinger wrote:
> On Friday 11 January 2008, H. Peter Anvin wrote:
> > 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.

so there's no confusion, since the building of the libc itself and using pure 
libc headers are generally unaffected, and all of the network linux headers 
are already screwed for userspace usage, i'm not against the proposed change 
from Peter.  it doesnt really make the situation any better/worse.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to