>Having done some research on this, Jim's script (with all the help he's >been getting on the lists and IRC) looks like the best bet. It's also >the 'Right Way Forward' (tm), as it will deal with the increasing >complexity of the Linux kernel. The trick will be making it work for >all the arches.
I have to disagree totally with this. I have had a good look at the headers problem over the last couple of weeks and Linux really does looks a complete mess in this regard.
Although the script might be a good *short term* plan I think an adequate long term solution requires a complete evaluation of *each* header - identifying what code to delete or include. From what I can see the majority of these headers are NOT required by userspace. I have got the basic LFS building with about 150 headers only. Possibly guess at another 150 for a complete set. (figures for i386 only)
The best solution *would* have been be that proposed on the LKML for a seperation into ABI headers but it does not seem that will happen in any sensible timescale - if ever. So I guess it's up to another group to take on this task and I'd have to say that LFS seems the best placed. Certainly not glibc. (glibc requires about 75 headers for i386 only).
I think eventually we need to go through each header identifying *and documenting* every piece of code to be included/removed. That really is the only way, and obviously it is a pretty massive + longer-term task.
And giving any script back to LKML will only encourage an inadequate short-term fix to be propagated indefinitely.
Roger -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page