Matthew Burgess: >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.
Jim Gifford: > 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 > re-evaluate. > Hi! 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 distinct patches: * git-hdrcleanup.patch ( Which generally just moves stuff around in order to put internal stuff inside #ifdef __KERNEL__ et al and remove bogus includes like <config.h> ) and * git-hdrinstall.patch ( Which creates a new Makefile target "headers_install. This runs selected headers through unifdef and installs them in /lib/modules/VERSION/kabi IIRC ) 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 themselves IIRC). 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 guys !) 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, Pantelis ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
