Re: A linux patch for a typo

["Ronald F. Guilmette" <rfg@monkeys.com>]

In message <Pine.LNX.3.95.980525104644.10365G-100000@penguin.transmeta.com>, yo
u wrote:

>I have long considered it _wrong_ for libc to have anything at all to do
>with the kernel header files, why do you still use them? It used to make
>sense back in -92 when the system was changing so fast that fundamental
>interfaces changed, and you were supposed to sometimes have to recompile
>your libc when you changed a kernel.
>
>Those days are long gone, please just take a snapshot of whatever random
>kernel you have today, and copy whatever defines you need from that kernel
>tree into your glibc tree, and then modify _that_. 

Linus,

H.J.'s most recent patch may indeed be buggy, but independent of that
issue/question, I am inclined to ask about the comment you have made which
I have quoted above.

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.

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.

I, for one, can assure you that I do tend to update my kernel at certain
times and my C library and system include files at other, different times.
I really don't want to get into situations where I get screwed because of
this, i.e. where my code still seems to compile just fine, but where some
small and subtle change in my interface to the new kernel that I have just
installed will cause my code to malfunction mysteriously at run-time.

Now I know that these days, cases like this (where the kernel interface is
changing in some big or small way) are rare, but it can still happen, and
prehaps not even because of anything that _you_ do.  For example, I may
soon be generating myself a custom kernel which will support a larger number
of file descriptors per process and also a larger number of fd's checked by
select(2) calls.  When I do that, I anticipate that I will probably just make
the relevant changes in the kernel include files, rebuild and reinstall the
kernel, and then rebuild and then reinstall my application(s).  I would
really not like to go through all of this only to find out that my applica-
tion is unaffected, and that it still believes that it is limited to 256 or
1024 (in the case of select(2)) fd's.


-- Ron Guilmette, Roseville, California ---------- E-Scrub Technologies, Inc.
-- Deadbolt(tm) Personal E-Mail Filter demo: http://www.e-scrub.com/deadbolt/
-- Wpoison (web harvester poisoning) - demo: http://www.e-scrub.com/wpoison/