On Sun, 18 Jan 1998, Michal Jaegermann wrote:
> Can somebody explain why this header separation between glibc and kernel,
> touted as "the best thing from a sliced bread", is really such a good
> thing? The only answer I have seen so far is that this will allow
> independent changes of various structures and definitions in kernel
> headers.
Also, it allows you to write a program once, and run it on tons of
different operating systems without making any changes.
If you rely on kernel includes, you have to make tons of changes to port a
program from, for example, FreeBSD to Linux or vice versa.
With glibc, you simply recompile it, and you have a working Linux version
of the program.
> That is the point! A lot of system utilities **has** to know these sizes.
> So far I have seen on this list a breakage in NFS, ncpfs, smbfs caused
> by a mismatch in definitions between these two sets of headers
Necessary in the switch - once every application is ported to work with
glibc (most of the important ones are, by now), it's ok - and you won't
have to rewrite NFS etc. every time the kernel is updated.
LLaP
bero
-- bero@bero-online.ml.org - ICQ/UIN 6545964 - http://www.star-trek.ml.org/ --
"Nobody will ever need more than 640k RAM!"
-- Bill Gates, 1981
"Windows 95 needs at least 8 MB RAM."
-- Bill Gates, 1996
"Nobody will ever need Windows 95."
-- logical conclusion