On Mit, 2006-03-15 at 06:27 +1100, Greg Schafer wrote: > Jürg Billeter wrote: > > > Yes, LLH fails that criteria and it ships with a lot of kernel-only > > stuff. Based on Jim's script I've written an extended version which > > removes a lot of headers that shouldn't be part of the linux glibc > > header set, AFAICT. > > Cool. But one has to ask how you arrived at the list of headers to remove > ie: what is your rationale? Also, the list of removals will likely need > reviewing every new kernel release. Not great from a maintenance POV..
Very short rationale is given on top of each file group. Detailed rationale for each header would unfortunately be too time consuming. Maintainenance shouldn't be that hard as it probably/hopefully doesn't happen that often that previously kernel-internal headers become kernel and userspace headers; if that's the case, only newly added header files need to be checked whether they are suitable for the linux glibc header set or should be removed. The advantage, compared to a whitelist, is that newer kernel versions should just work. The worst thing that may happen is that you have a few kernel-only headers in your include directory but you get all new functionality - assuming the new kernel headers aren't broken... It's not that much of a difference, though, whitelist and blacklist should both be ok for use and maintenance. Jürg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
