linux-kernel - Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>

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]

Date:	Fri, 18 Jan 2013 00:27:02 -0500
From:	Mike Frysinger <vapier@...too.org>
To:	David Miller <davem@...emloft.net>
Cc:	libc-alpha@...rceware.org, bhutchings@...arflare.com,
	yoshfuji@...ux-ipv6.org, amwang@...hat.com, tmb@...eia.org,
	eblake@...hat.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, libvirt-list@...hat.com,
	tgraf@...g.ch, schwab@...e.de, carlos@...temhalted.org
Subject: Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>

On Thursday 17 January 2013 23:55:24 David Miller wrote:
> From: Mike Frysinger <vapier@...too.org>
> > the kernel already exports many types with a __kernel_ prefix.  i changed
> > the kernel headers in Gentoo for a few releases (2.6.28 - 2.6.34) to do
> > the same thing to pretty much all the networking headers.  a few
> > packages broke, but the number was low, and trivial to fix (a sed would
> > do it most of the time).
> > 
> > it's also trivial for userland packages to detect that they need to do
> > this sort of thing in a local header by using linux/version.h and a set
> > of defines to redirect the new structure name back to the old one.
> > 
> > would be a lot cleaner to just break it and be done.
> 
> We are not at liberty to break something that has legitimately
> compiled successfully for two decades.

i doubt there are code bases that have compiled successfully for that long 
w/out being changed.  in fact, the kernel user headers (until recently) have 
been a volatile mess requiring constant care & feeding of user programs to 
keep compiling.  if anything, this would simply be maintaining the status quo 
for a bit longer.

> One thing you certainly don't have to be is happy about this header
> file situation, but you cannot use that dissatisfaction as
> justification to make the situation worse by breaking the build for
> people outside of the world you directly control.

i think you're making wrong assumptions about my position on the topic.  i 
never said i was against cleaning up the kernel user headers (and in fact, you 
can find many commits from me doing exactly that over the years in the kernel).
-mike

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