netdev - Re: [klibc] [patch] import socket defines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200801110403.00003.vapier@gentoo.org>
Date:	Fri, 11 Jan 2008 04:02:58 -0500
From:	Mike Frysinger <vapier@...too.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	klibc@...or.com
Subject: Re: [klibc] [patch] import socket defines

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

Download attachment "signature.asc " of type "application/pgp-signature" (836 bytes)