Headers was RE: PROPOSAL -- new group to handle multi-project tasks
pak_lfs at freemail.gr
pak_lfs at freemail.gr
Sat Jun 3 02:56:37 PDT 2006
>Jim, please see the following messages from Linus:
>Now, these are all to do with cleaning up the headers, rather than the
>original "make headers_install" proposal. However, the Makefile target
>will likely be added later on (and there's still plenty of time before
>2.6.18 to get it in) - this, I gather, is simply setting the stage for
>such a patch.
> As long as there is no way to use the kernel headers, this
> project is going to exist.
> If the make install_headers patch goes in, it will probably be time to
I 've been using David 's patches and Jim 's headers script on my new
experimental build. As it has been said here already, there are two, fairly
( Which generally just moves stuff around in order to put internal stuff
inside #ifdef __KERNEL__ et al and remove bogus includes like <config.h> )
( Which creates a new Makefile target "headers_install. This runs selected
headers through unifdef and installs them in /lib/modules/VERSION/kabi
Btw, both of these patches are in the latest -mm.
I believe the first has the most chances to be merged soon (2.6.18), since it
belongs to the kind of patches linus himself had _welcomed_ some time ago.
(Their position was that they aknowledge current headers are a bit of a mess,
cleanup patches would be accepted, but they wouldn't bother to do the job
The headers installed in kabi/ are currently not of much use, without perhaps
even more sanitizing (which is probably done in glibc-kernheaders?). So, the
best way I have currently found experimentally to work, is to use the
hdrcleanup patch from -mm in cooperation with Jim 's script. I have already
built two LFS systems this way and all worked flawlessly.
( That 's testimony to the goodness of the headers script by Jim et al, thanks
Ok, there was a little issue, that unistd.h was "oversanitized" (the macro
definitions for _syscall* macros were removed) so util-linux wouldn't build
fdisk, but that was easy to fix and if it remains in the new -mm I 'll
probably report it upstream.
So, my proposal for the headers is after the 6.2 release, when the trunk
switches to new gcc/glibc, that we should use Jim 's script. This will be
a solution for at least six months - a year, since it really doesn't seem that
upstream will have fixed things until then.
Now, if someone wants their headers to be clean and elegant, they can
always use the hdrcleanup.patch *combined* with Jim's script. We will
just need to keep an eye open to make sure that we don't duplicate
functionality from this patch on the script (we don't currently IMO).
Of course, if the kernel guys released an "AbiStyle" like their CodingStyle
document, describing what to put in the public part of the headers and what
not to and they reviewed patches for conformance, that would be just great,
but I don't expect it any time soon (although I could imagine Linus writing:
"Before we start, I suggest you take a copy of POSIX, LSB and SysV and
*not* read them. Burn them, its a great symbolic gesture ..."
Just my 2c,
http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου.
http://www.freemail.gr - free email service for the Greek-speaking.
More information about the lfs-dev