Messages in this thread | | | Subject | Re: Horrible things with 1.3.78 | Date | Wed, 27 Mar 1996 16:11:45 +0000 (GMT) | From | LeBlanc@mcc ... |
| |
> the libc includes should be distributed together with a copy > of the kernel includes... ... > You have my support. I suggested pretty much the same thing a few > weeks ago but nobody responded. ... > We had the same discussions more than 3 years. The conclusion was > libc and kernel shoulld share the same header files: > > 1. Avoid duplications. > 2. When kernel adds a new macro to a system call interface, there > is no need to recompile libc.
The problems are the dependencies, and in particular the inclusion of version.h, which changes every time the kernel is recompiled, in many C compilations. Ideally it seems to me that there ought to be three groups of include files:
common to kernel and ordinary / \ kernel only ordinary include files
All of the syscall numbers, structures, constants, etc, that need to be known by both would go in the common files, while the things that change from compilation to compilation would go in the kernel-only files. So far as I know this would meet everyone's objections. The difficulty is deciding what goes where in such a way that neither kernel development nor library development would be hindered.
This may be an ideal solution, but understand that it may be very hard to do. As someone else pointed out, the mutual dependency exists in all systems, but it is much less visible in commercial systems, since you don't have the freedom to change anything in the kernel source. When you relink the kernel, you can compile a special file containing, e.g., tables whose sizes change when you change the various constants, and the linker combines this with the binaries supplied by the manufacturerer. Because the operating system changes only very rarely (once a year or so), this can be made to work. But it would be very hard to do this with Linux, where there is a new kernel twice a week.
-- Owen LeBlanc@mcc.ac.uk
| |