>>>>> "magallon" == J A Magallon <[EMAIL PROTECTED]> writes:
Hi magallon> A plain copy will lead to inconsistencies for sure. No, this way will lead to inconsistencies. magallon> The problem is that glibc maintainers will not scan through magallon> kernel headers to extract public IOCTLs and so on. They just magallon> will copy the full kernel headers. So you can end up magallon> compiling an external module with the wrong headers (those magallon> of glibc instead of those of running kernel) if you miss the magallon> -I/usr/src/linux-???/include. yes, but if you compile and new kernel, you don't want to recompile your glibc & all your applications, do you? That is the reason that you need to have the values in glibc. Other thing is if you are recompiling, and you are including: -I/lib/modules/`uname -r`/build/include (that is the preffered aproach). If you do that, you know that you (perhaps) needs to recompile for next kernel version. magallon> The ideal (do not know if my children will see it) would be magallon> to join kernel and glibc developers for a week in a tropical magallon> beach, and define a common set of public kernel headers, to magallon> put in a place like /usr/include/linux or magallon> /usr/include/kernel. IE, define the interface between glibc magallon> and kernel. And let kernel and glibc use it instead of magallon> duplicate it. that could be an idea, but nobody volunteers to do that, and Linus has already stated that /usr/src/linux/include if _only_ for kernel use, if you want to to use that in user space, you need to copy the parts that you need. Notice that this is not such a big problem as it appears at first sight, just now there is code in glibc that does things like: if (linux_2_2) access struct stat22 else /* linux_2_4 */ access struct stat24 wherer stat22 & stat24 are different. They need to copy all the definitions to be able to work with different kernels, and once that you are doing that, everything works. Notice that for instance today, if you compiled glibc in one machine that has linux2_2 source, that glibc will not work in 24, and if you compiled in a machine with 24 includes, it will work in both, that means that glibc alread has the 22 copy of a lot of defintions, Linus is just requesting that they copy _everything_ that they need. And that will be better in the long run, as then they will be able to cope better with new incompatible versions of the kernel. As for the question of if that is doable or not, I think that dietlibc don't use the kernel headers, it has a copy of everything that it needs. That is a proof of concept that it is possible to da that. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
