On Fri, Sep 29, 2000 at 04:10:51PM -0700, H. Peter Anvin wrote:
> > > I find that the compile of gnome-utils fails as follows...
> > >
> > > In file included from /usr/include/linux/string.h:21,
> > > from /usr/include/linux/fs.h:23,
> > > from badblocks.c:43:
> >
> > Yes, a well-known phenomenon.
> > Kernel headers are to compile the kernel.
> > They are not for inclusion in user programs.
>
> It really doesn't work in practice. There are enough things that
> really need it.
Hmm. I describe the truth, and you know that it is the truth.
Given a user space utility that uses kernel includes - sooner
or later it will break. And if it uses <linux/fs.h> it will be sooner.
This state of affairs is unfortunate. But it is the state of affairs.
> We really need #ifdef __KERNEL__ (or is that #ifdef _LINUX now?) in
> the appropriate places.
That is what we did for a long time. But it does not really help.
It means that something is broken, someone notices, and three kernel
versions later it is fixed again.
That is no good. I cannot distribute mount and say: compile this
under Linux 2.1.117, not 118-120, 121-127 are good again, not 128-...
So, I see three solutions:
(i) The user space utility comes with a copy of the relevant part
of the kernel includes. When tunelp.c does not compile, take a
local copy of <linux/lp.h> and all is well again.
(ii) Use known good includes.
If /usr/include/{linux,asm} points at specially selected includes -
perhaps stripped of kernel stuff, and/or tested with a standard
collection of sources, then chances are much better that things
will work. Debian uses this.
(iii) Restructure the current system.
We really need a collection of include files that only
define the manifest constants and structures used for
communication with user space. These can then be used both
by glibc and by the kernel. This yields includes <linux/foo.h>
and <kernel/foo.h> and the former defines a constant API.
It ideally never changes, only is added to.
As you can see, (iii) doesnt exist yet, (ii) is present only
on some systems, so if one has a package that should compile
everywhere then (i) is really necessary.
There is an entirely different reason why (i) is required.
It may be desirable to have a mount source that allows
NFS v3 mounting even when compiled on a system where that
was not yet part of the kernel. In other words, it is bad
to have a dependence of the binary on the kernel source
installed at the moment of compilation.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:26 EST