Re: A linux patch for a typo

[Linus Torvalds <torvalds@transmeta.com>]

On Mon, 25 May 1998, Ronald F. Guilmette wrote:
> 
> The C library, among other things, is (in effect) my interface to kernel
> functionality... assuming that I am an applications programmer.  If I
> happen to install a new kernel someday, and if some small, obscure, but
> significant detail of that interface changes on me (and my application code)
> I definitely would like to feel assured that I _will_ automatically get the
> new #defines or dtructure definitions, or whatever when and if I recompile
> my old code in the new environment.  It seems to me that the best way to
> insure that there will not be a divergence between what the kernel actually
> expects and the interface that the system include files actually provide
> is to just make some of the system include files be links to (or includers
> of) the actual kernel include files.

This was the original reason for trying to use the kernel header files..

It's a good reason, and I'm not arguing otherwise. It used to make perfect
sense. 

However, while sharing header files has a few good things going for it, it
also has some bad things associated with it. 

The advantage of sharing files is that the change gets propagated back. 
That was a big advantage in -92 when we were adding ioctl numbers etc
almost weekly, as the system was fleshing out. So it definitely made sense
back then - especially as both the library and kernel were updated
frequently, so the advantages much outweighed the disadvantages. 

But the balance has certainly changed. These days the rate of change is
much slower - so the advantages of propagating the changes quickly between
libc and the kernel are much less in -98 than they were in -92.

At the same time, the rate of updates has slowed down a lot: people who
want to depend on stable versions tend to update once a year or something
like that, rather than weekly. And even the people who update the kernel
or glibcc weekly because they are in the development team of that piece of
code usually updates only one or the other - not both. 

In short, very few, if any, people get any advantage from the sharing any
more.

At the same time as the advantages of sharing have shrunk, the DIS-
advantages have grown much bigger. The sharing not only implies that
changes are moved back and forth, it also implies a dependency that
wouldn't otherwise be there. And while in -92 there were just a few
different library versions and less than a hundred different kernels,
today there are several hundred development versions of both the library
and the kernel, and the differences between different versions can be
really big (kernel-1.2.x is _very_ different from kernel-2.1.x, and libc-4
is very different from glibc-6). 

And yes, you can say "only this library is supported with this kernel",
but that isn't really realistic, is it? 

> I have trouble understanding why you think that doing this is a Bad Thing,
> and I would very much appreciate it if you would elaborate.

The reason it is _really_ bad is two-fold:

 - it makes it harder to maintain sanity. I have no idea which of the 1000
   different versions of libc happen to use which kernel header file, and
   exactly whgich things they depend on. So I have a very hard time making
   changes to kernel header files, which is just _wrong_. There have been
   too many problems caused by simple and obvious cleanups and
   re-organizations of the kernel header files.

   The same thing obviously cuts both ways: the libc team have totally
   unnecessary problems just trying to track different kernel header files
   etc.

 - the library is compiled for a certain kernel, whether you wish that to
   be true or not. When the kernel changes, I make sure that the old
   binary interfaces stay the same (so that old binaries still run), but
   the header file changes can then cause inconsitencies in any program
   that is compiled with the new headers but is linked against the old
   libc binary.

   As an example, let's imagine that I changed the "struct stat" type
   define in the kernel headers. I'd make the old stat system calls return
   the old interface, and create a new system call. Everything is fine,
   because old binaries run well, and new binaries work, right?

   Wrong. Programs compiled with the new header file will use the new
   "struct stat", but pass it to the old libc, which will use the old
   system call to fill it in. Blammo, you get completely incomprehensible
   behaviour.

   And before anybody tells me that libc already handles "struct stat"
   specially, then yes, I _know_. That's the point. Libc happens to think
   "stat" is special exactly because we've had this problem before. But
   imagine something else changing in similar ways.

The basic point is that the header files and the "libc.so" binary file
_have_ to match, as far as anything that "libc.so" has used goes. 
Otherwise you can get strange version skew. That version skew, together
with the maintenance problems on both sides definitely means that you do
NOT want to share the header files any more - because peoble want to be
able to update only the kernel, or only the library. 

I thought glibc had moved away from using kernel header files already. 
I've talked about this to various people before, and that was one of the
advantages with glibc as far as I was concerned. 

		Linus