On Thu, 27 Jul 2000, Jamie Lokier wrote:
>
> Linus Torvalds wrote:
> > In short, the _only_ people who should update their /usr/include/linux
> > tree are the people who actually make library releases and compile their
> > own glibc, because if they want to take advantaged of new kernel
> > features they need those new definitions.
>
> I've written quite a few programs that use new kernel features that
> aren't in Glibc. A recent one includes <linux/ppdev.h>. That's easy,
> an iocl. Another use O_NOFOLLOW, which wasn't defined in Glibc for a
> while.
This is true.
However, people who do these kinds of things know what they are doing.
People who follow new kernels, and actually write new programs to take
advantage of new kernel features are people who can easily handle the
issue of getting the new defines etc from the kernel header files.
This is obviously why there historically _was_ a symlink. There were tons
of new features all the time, and they were usually quite big. Besides,
nine years ago _everybody_ who used linux compiled their own kernels and
programs and knew exactly what they were up against.
These days, you usually need a single small define, or similar. The
problems the symlinks bring are not worth it any more. I would suggest
that your programs using new features should do something feature-specific
these days. For example, you can do one of any number of things (not all
are really good for O_NOFOLLOW, but you get the idea):
(a) explicit code to define it. In this case it's not very clean, as
O_NOFOLLOW happens to be one of the things where the value depends on
the architecture, but in many other cases this is a non-issue:
#ifdef __linux__
#ifndef O_NOFOLLOW
#ifdef __i386__
#define O_NOFOLLOW ...
#else
...
#endif
(b) You just use "-I/home/lk" and then use
#include "v2.3/linux/include/asm/fcntl.h"
and because you do this explicitly you'll be much more able to handle
the (in this case fairly unlikely) case of having those defines clash
with whatever the library headers do.
(c) do a simple "generation" script. This is what I'd do in the case of
O_NOFOLLOW. In your makefile, just have
nofollow.h:
grep define.*O_NOFOLLOW $(KERNELDIR)/include/asm-$(ARCH)/fcntl.h > nofollow.h
and you're done.
Note that the advantage of (a) is that it will actually compile and work
even on a machine that doesn't have the kernel sources installed at all.
So your program will compile even on a bog-standard RedHat/SuSE/whatever
installation, and if done right it will use the new feature on new kernels
and fall back on something else on old kernels.
The advantage of (b) is that at least it will be obvious _why_ it doesn't
compile when somebody else gets your source-code and notices that you seem
to be including header files directly from a development kernel tree..
The advantage of (c) is that in the specific case of "O_NOFOLLOW" and a
lot of other structures, this is a really easy approach. It doesn't work
that well for some other things, but it tends to work really well for the
simple "I want this particular #define from the kernel".
> I decided to tackle this by having autoconf read the value from
> <asm/fcntl.h> and define a macro with that value. (Because you can't
> include include <asm/fcntl.h> and <fcntl.h> at the same time). That
> turns out to more complicated than you'd think: <asm/fcntl.h> requires
> <linux/types.h>, which is incompatible with <stdio.h>. But it still
> works better, in the tradition of autoconf, than having a copy of the
> constant for every known architecture and not being able to use the
> feature on other architectures.
Hmm. That sounds fairly complex to me - see my (c) suggestion - but the
point is that yes, it can be done. And the other point is that by doing
it this way the onus of having to know what to do falls on the people who
_do_ know what to do.
There are a lot of people who want to download sources off the net and
compile and run them. Not all of them know (or _should_ know) what to do
when the system header files are acting up. So it should be the default
action to compile new kernels _without_ messing with the system headers,
so that you don't have to worry about other programs..
Yes, if you know what you're doing, you're free to do the symlink. But
it's not really a supported environment: I do not like making the kernel
headers less readable by having various user-level dependencies on them. I
_do_ end up accepting silly "#ifdef __KERNEL__" stuff in order to make old
libc-5 etc installations happy with the symlink, but I definitely don't
guarantee that that will always be the case (and it certainly historically
_hasn't_ always been the case that the kernel headers work together with
the userland headers).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:23 EST