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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <200801110257.42272.vapier@gentoo.org>
Date:	Fri, 11 Jan 2008 02:57:41 -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:
> > 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

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