: >> I think this is a bad hack. Do you really want to duplicate kernel
: >> includes in all kinds of packages? This gives bad source control problems
: >> and makes extending the kernel very difficult .
: >
: > Talk to Linus about this. His intention is to have no user-level code
: > using kernel headers and I agree. This also means that very special
: > headers (like the filesystem headers) will have to come with the
: > package which need them.
: This is a very bad idea. If he said this he is just misguided.
: Maybe he doesn't need to fix nettools when they break..
: Do you really advocate duplication of kernel includes as a good solution?
: Fixed == duplicating the kernel includes into the program source? For me
: this is not a mess, this is just generating a hard to maintain mess for
: dubious gains.
and earlier:
: With a few #ifdef __KERNEL__s many
: of the kernel includes could be made 'glibc-ready'
Hmm - a handful of times each year I release a version of mount.
Every now and then (latest last weekend) I prepare a new version
of util-linux.
Almost 100% of the problems are with the kernel includes.
Take a random example, cytune.c. It contains
#include <linux/cyclades.h>
But such includes are asking for trouble.
Some data structures in <linux/cyclades.h> need <linux/tqueue.h>
(with older kernels), so we also have to include that. But the latter
includes much more kernel-specific junk, so that including
<linux/tqueue.h> leads to compilation errors on 2.0.34.
Yes, "a few #ifdef __KERNEL__s" are certainly needed, and they
have been needed the past five years. Not all kernel hackers
have the discipline to worry about user name space problems.
There has not been a moment in time the past five years that all
kernel header files were clean.
This is typical. In unimportant cases like cytune, I just choose
a solution that works for recent kernels without worrying too
much about ancient systems. In cases like mount I spend much
more effort to create a source that (i) compiles everywhere,
and (ii) produces a binary that can be moved to machines with
a different kernel and still works.
[complaints about the current version are welcome]
But such a goal is completely unattainable if one includes
<linux/fs.h>. On the other hand, <linux/fs.h> is needed for the
mount manifest constants. There is no other solution than to duplicate
these manifest constants.
You say `generating a hard to maintain mess'.
Possibly. Since previous time one more manifest constant has been
added, so a line
#define MS_NODIRATIME 2048
was required.
(By the way, there is a conflict here: 2.0.34 defines a different
meaning for the bit 2048.)
Copying the kernel headers afresh for each release, in the cases
where one wants new functionality to be available, and removing
all that should have been inside #ifdef __KERNEL__s, is, as far as
I can see, the only solution that works.
A thicket of #ifdef's would handle old kernels, but it is impossible
to predict what header files from 2.0.35 will be safe to include.
Now from the above you might get the impression that avoiding
kernel includes has to be done for practical reasons only.
But there are theoretical reasons as well. It is very undesirable
that one would have to worry under what kernel a utility was
compiled. Often that is not known anymore. But it happens that
the bug one is looking for is in, or caused by, the kernel headers,
so that an old binary functions well, but the binary one gets from
recompiling the same sources with the same compiler and the same libc
doesnt work anymore. (This happens. Long ago I wasted some time
because in some net header an int had been changed into an unsigned int.)
With private copies of the kernel headers it is easier to create
a reproducible situation.
Eventually all software writers should aim for
a `#include <linux/foo.h>'-free source.
With glibc this is possible to a much higher degree than with libc 4/5.
(By the way, Alan, in case you read this, the two occurrences
of 2.0.34 in the above point out flaws that you might consider
rectifying should there ever be a 2.0.35.)
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu