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, 22 Jun 2007 01:59:07 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	david@...g.hm
Cc:	Joerg Schilling <Joerg.Schilling@...us.fraunhofer.de>,
	schilling@...us.fraunhofer.de, linux-kernel@...r.kernel.org,
	"Mike Frysinger" <vapier.adi@...il.com>
Subject: Re: Linux Kernel include files

On Friday 22 June 2007, david@...g.hm wrote:
> this has been discussed many times and the answer is that the kernel is 
> not gong to change it's side of things to ANSI C.

I don't think that's entirely true with regard to the include files.
We have always tried not to step on anyone's toes there, e.g. regarding
the use of __u32 vs. uint32_t style types. It's certainly desirable
to make the kernel headers that are _meant_ for inclusion compatible
with standard compilers.

Mike Frysinger has posted a few patches that make the installed headers
friendlier to strict C99 users. While there was some negative feedback
about these patches, it was not about the idea of making the installed
headers C99 clean, but rather about the question whether those non-clean
parts should be exported in the first place.

Now whether a specific header file should be installed and potentially
included in user space is certainly debatable in many cases, but at
least it's now clearly defined through the include/*/Kbuild files.
If someone has a good reason to change which files are exported, he
should simply submit a patch against the list of exported files.

> that doesn't mean that one of the many projects out there to create 
> seperate interface headers won't do this.

Those projects are all practically dead, since we have the
'make headers_install' target in the Linux source.

	Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ