Re: /usr/include/linux and /usr/include/asm?
On Tue, 29 Jun 1999, Evan Van Dyke wrote:
> *SNIP*
> > However, I expect I'm the only one who thinks that's the proper
> > approach so, how's this for a solution: Give the /usr/include/asm and
> > /usr/include/linux directories up as lost causes. Instead, define new
> > directories. Say /usr/include/kernel-asm and /usr/include/kernel-linux.
> > Make THEM symlinks to the appropriate directories in the kernel source
> > tree. I would do this on my own computer, but I don't really get any
> > benefit from it unless everyone else, particularly those who develop
> > modules and whatnot, decides to use the same convention.
> > Therefore, we then attempt to convince people to actually use those
> > directories instead of /usr/include/asm and /usr/include/linux for the
> > good reasons that we've discussed.
> If you havn't read the letter by Linux Torvalds that was referred to under
> this thread within the last few days, I suggest that you do so.
I read it. In fact, the message that you quote was primarily in response
to that message. I UNDERSTAND the problem. I solved similar problems
back 15 years ago when I first started debugging clibs. It's the solution
that I find lacking. Too bad you didn't quote the part of my message that
was really important: Making my life tougher because it's easier for me to
deal with it than Joe Random Luser is NOT AN ACCEPTABLE SOLUTION! Yes, I
can deal with it Joe Random Luser, but I shouldn't have to.
> The obvious choice seems to be /usr/src/linux/include/linux and
> /usr/src/linux/include/asm as that is where most people store their
> kernel source. Why clutter up /usr/include more with kernel-specific
> headers? The entire point is that the /usr/include/* headers should be
> kernel-independant after all.
Why is that the point? If that's the point, it's a damn stupid one.
Look, header files go under /usr/include and /usr/local/include. Since
the header files that are kernel specific aren't local to the system, they
should be accessible under /usr/include. I should be able to refer to
them like that. THAT is what is obvious to me.
Why clutter up /usr/include with directories containing kernel-specific
headers? Well, why clutter it up with omniORB and ggi and php3? Because
/usr/include and the directories underneath are where header files GO,
aren't they? Having two sets of files with identical names and nearly
identical contents just galls me. What do I care what kernel the glibc
maintainer built libc.so.6 on? Why should I keep those files around?
The real issue is one that I talked about in my original message:
idempotence. While I agree that libc has to know about the kernel calls so
that it can wrap them in C-standard functions, it is apparent that glibc,
at least, knows far more about the internals of the kernel than is good
for it. It is essential that a given version of glibc be able to run on
newer kernel versions and on patched kernels. That requires careful
design and some foresight, which appears to be lacking in this case.
Let's take an example or two from the message from Linus Torvalds:
The use of the NR_OPEN constant. The kernel (apparently---I just skimmed
over it) uses NR_OPEN to set how many file handles any given task must
have. That is, it allocates an array of NR_OPEN "struct file *" for each
task that is forked. (The code is in kernel/fork.c, if you have a mind.)
Why does glibc refer to this constant anywhere? The number of files that
the kernel allows to be opened doesn't necessarily have anything to do
with the number of files glibc allows you to open. I suppose that glibc
might put an array of size NR_OPEN in order to hold the file handles, but
that's dumb. The ISO C standard says that the constant that defines the
maximum number of open files is FOPEN_MAX, and it is far smarter to put
your file handle in the FILE struct and declare your FILE array to be of
size FOPEN_MAX.
#define FOPEN_MAX to be the same as NR_OPEN? Use the same sigset_t for
both glibc and the Linux kernel? Yes, you COULD do that, but those things
don't necessarily have anything to do with each other, and it is poor
practice to use the same abstraction to refer to unrelated things even if
they happen to be the same at some point. libc abstractions, what most
programs use, are NEVER required to be the same as the kernel
abstractions.
While I agree that you can work around the problem by requiring that
/usr/include/asm and /usr/include/linux be the contents of the directories
/usr/src/linux/include/asm and /usr/src/linux/include/linux on the system
used by the builder of the glibc and by requiring that the kernel source
must ALWAYS be in /usr/src/linux, but that is not the correct solution.
That is a massive kluge needed because people can't seem to be bothered to
do things correctly. The correct solution is to eliminate those instances
where constants are used for purposes that they have no business being
used for. It's like defining the FOPEN_MAX to be sizeof(double) because
on some computers sizeof(double) is 8 and 8 is an acceptable value for
FOPEN_MAX. Yes, it works, at least some places, but it's stupid.
--
Jonathan Guthrie (jguthrie@brokersys.com)
Brokersys +281-895-8101 http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX 77014, USA
Reply to: