RLIM_INFINITY inconsistency between archs
Boszormenyi Zoltan
I have problems compiling egcs snaphots with 2.4.0-test kernel sources
on a glibc-2.1.2 system. (RH 6.1) The problem can be reduced to this:
*****test.c**************
#include <sys/resource.h>
int main(void) {
return 0;
}
*****test.c**************
[root@localhost /root]# gcc -Wall -o test test.c
In file included from /usr/include/sys/resource.h:25,
from test.c:1:
/usr/include/bits/resource.h:109: warning: 'RLIM_INFINITY' redefined
/usr/include/asm/resource.h:25: warning: this is the location of the
previous definition
*************************
/usr/include/asm is a symlink to /usr/src/linux/include/asm, as in the
original distribution but /usr/src/linux is a 2.4.0-testX tree.
With a 2.2.X source tree, it does not produce any warning.
Because of the warning above, egcs' configure script produces the
following:
*****auto-host.h*********
...
/* Define if you have the getrusage function. */
#define HAVE_GETRUSAGE 1
...
/* Define if you have the <sys/resource.h> header file. */
/* #undef HAVE_SYS_RESOURCE_H */
...
*****auto-host.h*********
Because of this gcc.c will not #include <sys/resource.h>, but it wants to
use e.g. struct rusage and getrusage().
Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard
"don't use kernel headers directly" answer. But neither gcc.c,
neither the above small program use kernel headers. I suppose he
referred to /usr/include/linux/* as (I think) he did not understand me.
I looked at the kernel sources and found that two architectures
(ppc and sh) protects RLIM_INFINITY with #ifdef __KERNEL__ ... #endif
so it does not conflicts with glibc. The attached patch does the same
on all other architectures.
The other solution would be to fix glibc so it does not redefine
RLIM_INFINITY but that is the glibc developers' business.
Regards,
Zoltan Boszormenyi <zbo...@mail.externet.hu>
Linus Torvalds
Boszormenyi Zoltan <zbo...@externet.hu> wrote:
>
>/usr/include/asm is a symlink to /usr/src/linux/include/asm, as in the
>original distribution but /usr/src/linux is a 2.4.0-testX tree.
>With a 2.2.X source tree, it does not produce any warning.
I've asked glibc maintainers to stop the symlink insanity for the last
few years now, but it doesn't seem to happen.
Basically, that symlink should not be a symlink. It's a symlink for
historical reasons, none of them very good any more (and haven't been
for a long time), and it's a disaster unless you want to be a C library
developer. Which not very many people want to be.
The fact is, that the header files should match the library you link
against, not the kernel you run on.
Think about it a bit.. Imagine that the kernel introduces a new "struct
X", and maintains binary backwards compatibility by having an old system
call in the old place that gets passed a pointer to "struct old_X".
It's all compatible, because binaries compiled for the old kernel will
still continue to run - they'll use the same old interfaces they are
still used to, and they obviously do not know about the new ones.
Now, if you start mixing a new kernel header file with an old binary
"glibc", you get into trouble. The new kernel header file will use the
_new_ "struct X", because it will assume that anybody compiling against
it is after the new-and-improved interfaces that the new kernel
provides.
But then you link that program (with the new "struct X") to the binary
library object archives that were compiled with the old header files,
that use the old "struct old_X" (which _used_ to be X), and that use the
old system call entry-points that have the compatibility stuff to take
"struct old_X".
Boom! Do you see the disconnect?
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. That way there is never any
conflict between the library and the headers, and you never get warnings
like the above..
>Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard
>"don't use kernel headers directly" answer. But neither gcc.c,
>neither the above small program use kernel headers. I suppose he
>referred to /usr/include/linux/* as (I think) he did not understand me.
No. He really meant that you should not use the kernel headers: you
should use the headers that glibc came with. It is probably a redhat bug
that those headers were a symbolic link.
I would suggest that people who compile new kernels should:
- NOT do so in /usr/src. Leave whatever kernel (probably only the
header files) that the distribution came with there, but don't touch
it.
- compile the kernel in their own home directory, as their very own
selves. No need to be root to compile the kernel. You need to be root
to _install_ the kernel, but that's different.
- not have a single symbolic link in sight (except the one that the
kernel build itself sets up, namely the "linux/include/asm" symlink
that is only used for the internal kernel compile itself)
And yes, this is what I do. My /usr/src/linux still has the old 2.2.13
header files, even though I haven't run a 2.2.13 kernel in a _loong_
time. But those headers were what glibc was compiled against, so those
headers are what matches the library object files.
And this is actually what has been the suggested environment for at
least the last five years. I don't know why the symlink business keeps
on living on, like a bad zombie. Pretty much every distribution still
has that broken symlink, and people still remember that the linux
sources should go into "/usr/src/linux" even though that hasn't been
true in a _loong_ time.
Is there some documentation file that I've not updated and that people
are slavishly following outdated information in? I don't read the
documentation myself, so I'd never notice ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Jeff Lightfoot
> Is there some documentation file that I've not updated and that people
> are slavishly following outdated information in? I don't read the
> documentation myself, so I'd never notice ;)
~ 33 or so files reference /usr/src/linux in the Documentation
subdirectory.
*I'm too stupid to make a patch* :-)
--
Jeff Lightfoot --- jeffml at pobox.com --- http://thefoots.com/
=======================================================================
"I see the light at the end of the tunnel now ... someone please tell
me it's not a train" -- Cracker
Jamie Lokier
> 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.
I know you want every application to copy the ioctl & structure
definitions it uses -- and this does work. But it's just _so_ ugly when
you want to pass a small program to someone else and must include the
set of header files it uses too.
O_NOFOLLOW's definition varies with each architecture. So following
your suggestion, I'd have to distribute that program with the
appropriate <asm-$arch/fcntl.h> for every value of $arch. And even that
doesn't let the program compile on new architectures later down the
line.
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.
-- Jamie
André Dahlqvist
> Is there some documentation file that I've not updated and that people
> are slavishly following outdated information in? I don't read the
> documentation myself, so I'd never notice ;)
Like someone else pointed out there are many references to
/usr/src/linux in the documentation, but I think the main README file is the
one most people look at. How about this patch for a start?
--- linux-2.4.0-test5-pre6/README Thu Jul 27 14:12:51 2000
+++ linux/README Thu Jul 27 15:00:26 2000
@@ -59,23 +59,22 @@
INSTALLING the kernel:
- - If you install the full sources, do a
+ - If you install the full sources, put the kernel tarball in a
+ directory where you have permissions (eg. your home directory) and
+ unpack it:
- cd /usr/src
gzip -cd linux-2.3.XX.tar.gz | tar xvf -
- to get it all put in place. Replace "XX" with the version number of the
- latest kernel.
+ Replace "XX" with the version number of the latest kernel.
- You can also upgrade between 2.3.xx releases by patching. Patches are
distributed in the traditional gzip and the new bzip2 format. To
- install by patching, get all the newer patch files and do
+ install by patching, get all the newer patch files, enter the
+ directory in which you unpacked the kernel source and execute:
- cd /usr/src
gzip -cd patchXX.gz | patch -p0
or
- cd /usr/src
bzip2 -dc patchXX.bz2 | patch -p0
(repeat xx for all versions bigger than the version of your current
@@ -88,17 +87,15 @@
process. It determines the current kernel version and applies any
patches found.
- cd /usr/src
- linux/scripts/patch-kernel
+ linux/scripts/patch-kernel linux
- The default directory for the kernel source is /usr/src/linux, but
- can be specified as the first argument. Patches are applied from
- the current directory, but an alternative directory can be specified
- as the second argument.
+ The first argument in the command above is the location of the
+ kernel source. Patches are applied from the current directory, but
+ an alternative directory can be specified as the second argument.
- Make sure you have no stale .o files and dependencies lying around:
- cd /usr/src/linux
+ cd linux
make mrproper
You should now have the sources correctly installed.
@@ -196,15 +193,15 @@
do a "make modules_install".
- In order to boot your new kernel, you'll need to copy the kernel
- image (found in /usr/src/linux/arch/i386/boot/bzImage after compilation)
+ image (found in .../linux/arch/i386/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
- For some, this is on a floppy disk, in which case you can "cp
- /usr/src/linux/arch/i386/boot/bzImage /dev/fd0" to make a bootable
- floppy. Please note that you can not boot a kernel by
- directly dumping it to a 720k double-density 3.5" floppy. In this
- case, it is highly recommended that you install LILO on your
- double-density boot floppy or switch to high-density floppies.
+ For some, this is on a floppy disk, in which case you can copy the
+ kernel bzImage file to /dev/fd0 to make a bootable floppy. Please note
+ that you can not boot a kernel by directly dumping it to a 720k
+ double-density 3.5" floppy. In this case, it is highly recommended
+ that you install LILO on your double-density boot floppy or switch to
+ high-density floppies.
If you boot Linux from the hard drive, chances are you use LILO which
uses the kernel image as specified in the file /etc/lilo.conf. The
--
// André
Mike A. Harris
This is wonderful advice below Linus. I think that this would
solve a great many problems for many people. I have on more than
one occasion left devel source under /usr/src/linux, and compiled
something to have it fail. I was under the assumption from the
kernel docs that the kernel HAD to be compiled in there. I very
much like the idea of what you describe below however as it
solves NUMEROUS problems indeed. This information should be put
in the top level README file, and emphasis put on the 'dont
compile in /usr/local' part, because it would sure save people a
lot of headaches IMHO.
Thanks very much for clarifying this for all.
TTYL
>No. He really meant that you should not use the kernel headers: you
>should use the headers that glibc came with. It is probably a redhat bug
>that those headers were a symbolic link.
>
>I would suggest that people who compile new kernels should:
>
> - NOT do so in /usr/src. Leave whatever kernel (probably only the
> header files) that the distribution came with there, but don't touch
> it.
>
> - compile the kernel in their own home directory, as their very own
> selves. No need to be root to compile the kernel. You need to be root
> to _install_ the kernel, but that's different.
>
> - not have a single symbolic link in sight (except the one that the
> kernel build itself sets up, namely the "linux/include/asm" symlink
> that is only used for the internal kernel compile itself)
>
>And yes, this is what I do. My /usr/src/linux still has the old 2.2.13
>header files, even though I haven't run a 2.2.13 kernel in a _loong_
>time. But those headers were what glibc was compiled against, so those
>headers are what matches the library object files.
>
>And this is actually what has been the suggested environment for at
>least the last five years. I don't know why the symlink business keeps
>on living on, like a bad zombie. Pretty much every distribution still
>has that broken symlink, and people still remember that the linux
>sources should go into "/usr/src/linux" even though that hasn't been
>true in a _loong_ time.
>
>Is there some documentation file that I've not updated and that people
>are slavishly following outdated information in? I don't read the
>documentation myself, so I'd never notice ;)
>
> Linus
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
... Our continuing mission: To seek out knowledge of C, to explore
strange UNIX commands, and to boldly code where no one has man page 4.
Theodore Y. Ts'o
Date: 27 Jul 2000 00:39:51 -0700
I would suggest that people who compile new kernels should:
- NOT do so in /usr/src. Leave whatever kernel (probably only the
header files) that the distribution came with there, but don't touch
it.
- compile the kernel in their own home directory, as their very own
selves. No need to be root to compile the kernel. You need to be root
to _install_ the kernel, but that's different.
- not have a single symbolic link in sight (except the one that the
kernel build itself sets up, namely the "linux/include/asm" symlink
that is only used for the internal kernel compile itself)
May I suggest one slight change to this list? /usr/src/linux should be
a symlink to the header files of whatever kernel is being booted by
default. So you can compile your own kernel in your own home directory,
but when you install your own kernel as the default boot kernel,
/usr/src/linux should point to the header files of that kernel. As you
say, it requres root to _install_ your own kernel, and that point, you
can point /usr/src/linux at the appropriate place.
This allows source packages which generate kernel modules which have to
link against the current kernel ---- such as the external pcmcia driver,
hich you've recommended that distro's use since 2.4's pcmcia support
isn't quite up to snuff yet ---- be able to reliably find (or at least
present the user with a sensible default) the header files of the kernel
which is being installed as the default boot kernel.
And this is actually what has been the suggested environment for at
least the last five years. I don't know why the symlink business keeps
on living on, like a bad zombie. Pretty much every distribution still
has that broken symlink, and people still remember that the linux
sources should go into "/usr/src/linux" even though that hasn't been
true in a _loong_ time.
The problem is that unless you are trying to say that you want to outlaw
external source packages which generate kernel modules, there needs to
be some way for such packages to be able to find the kernel header
files.
Other solutions include having a standard mechanism for dropping
external packages into the kernel source tree, which will then compile
those modules as their own. (Apache supports a model like this).
Or, we could make some other symlink point at the sources of the kernel
which is booting by default.
The fact that people need to solve this problem is one of the reasons I
think the old model has lived on for so long.
The other problem which comes up is that they need to compile some new
kernel utility program, which by virtue of the fact that it's using some
new ioctl, needs access to the latest kernel header files. These
programs are the exception, though, not the rule, and one can argue that
in this case they can simply carry their own header files with them.
(That's incredibly clumsy, though, and means that a lot of header files
will have to get duplicated; and as one person has pointed out, in some
cases, may mean that you have to bring several copies of the the asm-*
header files since some ioctl structures are architecture dependent.)
Alternatively, I suppose you could say that all such kernel utility
programs have to be packaged with the kernel; but do we really want to
be making the kernel that much bigger? :-)
- Ted
Linus Torvalds
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
Theodore Y. Ts'o
From: Linus Torvalds <torv...@transmeta.com>
(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
The only problem with this sort of thing is that you need to somehow
find KERNELDIR. Some kind of convention to make it easy to set
KERNELDIR, even if it isn't /usr/src/linux because you don't like the
history and because stuff you don't like is depending on /usr/src/linux,
would be really useful. Say, for example, /boot/kernel-headers being a
symlink to the kernel headers corresponding to the default kernel to be
booted?
- Ted
Jesse Pollard
Might I suggest creating a "/lib/include" that works something like
the /lib/modules where the kernel name is used to generate the directory
for the kernel include files?
That way the "uname -r" command could be used to set a symbolic link
to point to the correct include files at boot time (or install time).
Since /lib/include could contain
2.4.0/(kernel includes)
2.4.0-SMP/(kernel includes)
2.4.0-RSBAC.SMP/(kernel includes)
Then at boot time (before SV init or init really takes over)
the commands:
( cd /lib/include
rm linux
ln -s `uname -r` linux )
This way the kernel that is active would be selecting the correct includes.
The build makefile could have an additional target - includes, that
would create the directory and copy the include files.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
Jamie Lokier
> (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
>
> The only problem with this sort of thing is that you need to somehow
> find KERNELDIR.
Indeed, that's why I #include <asm/fcntl.h>, to find the header file.
I've assumed that <asm/fcntl.h> reflects something close to the current
kernel, which wouldn't work with Linus' setup.
Probably I should follow Linus' (a) suggestion (define the constants in
the program for combination of Linux & known architecture), and also
accept the value if it appears through plain old <fcntl.h>. Any newer
architecture than current ones in the kernel tree ought to be using a
Glibc that defines the thing I'm interested in via plain old <fcntl.h>.
-- Jamie
Linus Torvalds
On Thu, 27 Jul 2000, Linus Torvalds wrote:
>
> What I mean is that the above generation-script should be generated
> _once_. The source gets distributed with the generated file, so that
> whatever happens you at least get reliable results in a reasonably
> heterogenous environment.
Put another way that maybe is a clearer example:
- when I download the binary rpm of package "foo-2.3.5.rpm", should I
really have to care on what machine it was compiled?
A lot of old-time UNIX people seem to think that everybody compiles
sources themselves. That's madness. Yes, it's important that you _can_.
But you shouldn't have to. If I hear that the new feature 2.3.5 of package
"foo" supports the new filesystem layout that I've been waiting for,
should I have to pray that the person who compiled the binary happened to
use one of the development kernels where that feature was actually
implemented?
Or should I have to recompile it myself to make sure?
Or, wonder of wonders, should it just WORK?
I think the latter. And I hope I've made clear to everybody why a software
package must NOT EVER depend on what kernel version happened to be
installed when it was compiled. And why it is so _important_ that nobody
even by mistake does this. EVER.
The defense rests.
Linus
Linus Torvalds
On Thu, 27 Jul 2000, Theodore Y. Ts'o wrote:
>
> (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
>
> The only problem with this sort of thing is that you need to somehow
> find KERNELDIR. Some kind of convention to make it easy to set
> KERNELDIR, even if it isn't /usr/src/linux because you don't like the
> history and because stuff you don't like is depending on /usr/src/linux,
> would be really useful. Say, for example, /boot/kernel-headers being a
> symlink to the kernel headers corresponding to the default kernel to be
> booted?
No. You really miss the point. That _still_ makes the program depend
differently on which kernel happens to be on which machine. Which is so
obviously wrong that I don't understand how anybody can accept it.
I know people who _routinely_ compile stuff over NFS on another machine
simply because that other machine is a lot faster, and the network is
fast. They expect the binary to be the same. And I agree 100% percent. It
should NOT depend on your particular kernel configuration (and yes, some
kernel header files actually _change_: they depend on whether the kernel
was compiled for a PII or a i386 etc).
Say you have a build-server that runs an older kernel because it doesn't
really matter, and it's not running gnome etc. Say your desktop uses USB
and you've upgraded. Or the reverse may be true, where the build-server is
a SMP machine that uses a newer kernel because it handles the load better.
With your approach, that build-server would be unable to generate programs
that take advantage of the new features that somebody wanted to have in
the program. They would generate programs that are doing things that the
locally generated programs wouldn't be doing.
What I mean is that the above generation-script should be generated
_once_. The source gets distributed with the generated file, so that
whatever happens you at least get reliable results in a reasonably
heterogenous environment.
A "normal user" would never generate nofollow.h at all. The generation
script would be used by the _maintainer_ or by people who add new features
(And yes, in the above example it's rather simplistic. A real example
would generate the proper architecture ifdef's etc).
I expect that library versions and compiler versions should matter to
compiling programs. But I do _not_ want kernel versions to do that. It's
already painful for people that you have to have the right library
version. I'd _hate_ to see source code that says "requires kernel 2.3.99
or higher sources in /usr/src/linux" in addition to saying "needs
glibc-2.1.2 or newer for threading reasons".
Linus Torvalds
On Thu, 27 Jul 2000, Theodore Y. Ts'o wrote:
>
> May I suggest one slight change to this list? /usr/src/linux should be
> a symlink to the header files of whatever kernel is being booted by
> default. So you can compile your own kernel in your own home directory,
> but when you install your own kernel as the default boot kernel,
> /usr/src/linux should point to the header files of that kernel. As you
> say, it requres root to _install_ your own kernel, and that point, you
> can point /usr/src/linux at the appropriate place.
No.
It still means that the kernel header files would have to be source-level
backwards compatible forever. Something which hasn't been true in the
past, and I don't want to be true in the future either. It's been damn
painful to not be able to clean stuff up because some user-level setup is
wrong.
> The problem is that unless you are trying to say that you want to outlaw
> external source packages which generate kernel modules, there needs to
> be some way for such packages to be able to find the kernel header
> files.
Yes. By hand. By the maintainer. And _independently_ of what random user
Joe Blow has on his particular installation.
Because it's not unreasonable AT ALL to have those packages be compiled
with newer header files than the user even has access to. Imagine a ext2
library that wants to support new features of the filesystem, compiled on
a box that only has 2.2.13 installed. Neve rever had anything newer.
Should that newer source package dumb itself down to 2.2.13 level, so that
the e2fsck doesn't know how to handle new filesystems? Sure, the user
obviously isn't using them _now_, but wouldn't it be a lot nicer if you
just had a source tree that ended up generating the same binary that you
as the maintainer has? With all the new features, just suppressed by the
fact that it ends up running on a old-style filesystem image..
Trust me, it's STUPID to have user-level binaries that end up different
depending on what machine they were compiled on. We've had exactly that
happen, and it's a BUG. It's nasty to debug.
Think about it. You have machine X and machine Y, and they both have the
ext2-programs compiled with the same compiler from the same sources with
the same libraries. Would you _really_ consider it acceptable if they act
differently?
I don't. And that is why I will continue to maintain that it is WRONG to
have that symlink. No ifs, buts of other crap. Just face reality.
Theodore Y. Ts'o
From: Jesse Pollard <pol...@tomcat.admin.navo.hpc.mil>
Might I suggest creating a "/lib/include" that works something like
the /lib/modules where the kernel name is used to generate the directory
for the kernel include files?
This is fine with me; as long as there's some what of finding the kernel
headers needed to build kernel modules. (I'm not talking about user
programs, Linus, I'm talking about kernel ***modules***)
/lib/include and /lib/include/`uname -r`, if we all can agree on it as a
standard, is as good as any.
(Note that's not just the /lib/include/linux we would need symlinked; we
would also need /lib/include/asm as well.)
- Ted
Jamie Lokier
> Linus Torvalds <torv...@transmeta.com> writes:
> > I expect that library versions and compiler versions should matter to
> > compiling programs. But I do _not_ want kernel versions to do that. It's
> > already painful for people that you have to have the right library
> > version. I'd _hate_ to see source code that says "requires kernel 2.3.99
> > or higher sources in /usr/src/linux" in addition to saying "needs
> > glibc-2.1.2 or newer for threading reasons".
>
> these sudden, unplanned changes is what makes it necessary to not add
> all the content to the libc headers.
Um, changes to the kernel do _not_ affect user-kernel API. Well, they
shouldn't anyway. They just add more features, which newer user-space
can use if it knows about them. So what is your reason for having to
release a new Glibc every week?
> Until you provide solutions for this you cannot expect others to do
> more work. I would have to release a new glibc version every week
> since something changed and somebody will run into the problems. And
> no, your argument that the people who are doing such low-level work
> should know what to do doesn't cut.
The subject of this thread is RLIM_INFINITY. There's an example that
wouldn't be a problem at all if you didn't include kernel headers.
> In addition, and I repeat this probably for the thousands time, where
> the f*ck is the sysconf() functions which is so very much needed?
Something for a separate thread...
> Those people might know, but what they produce and ideally distribute
> in source form has to be compiled by the clueless. They don't know
> how to change their system (if they even have the permission) and
> hardcoding new values is also out of question.
Why is hardcoding a kernel-user API, which is set in stone by binary
compatibility requirements anyway, out of the question? They can be
hard coded in the distributed source, so that clueless users don't need
to know anything.
Hmm... well that doesn't really explain why pppd comes with copies of
the kernel headers but will use ones from the installed kernel if
they're newer... Why is that?
> Maybe you should spent some time thinking how *you* can improve the
> process of using more recent kernels before complaining about others.
> The first and obvious thing is to implement __sys_sysconf (maybe do it
> on top of sysctl, I don't care).
Using a new kernel is easy. Compile, install, reboot. Provided the
Glibc headers don't point to the new kernel's headers it works fine :-)
-- Jamie
Theodore Y. Ts'o
From: Linus Torvalds <torv...@transmeta.com>
> It would be nice, however, if there was a painless way to
> compile such external kernel modules so they easily work with whatever
> kernels happens to be on the machine.
You're right, right now kernel modules need some way of specifying where
the kernel is. I've always just had a define at the top of a makefile that
the user actually had to edit by hand (this was how early USB-development
was done, for example). Not very pretty, I guess. But at least it doesn't
screw the "normal" user packages.
I'd really, really, like some kind of convention that could be
standardized. It could be any one of
/usr/src/linux
/lib/include/`uname -r`
../linux
(the last requires that pcmcia and Rocketport packages have to be in the
same top-level directory as the kernel source tree).
I could live with any of these; as long as we all can agree on a single
convention, so that default is always right. If you don't like
/usr/src/linux because of the past history, and how user-mode packages
are using it incorrectly, let's create a new convention. I personally
think /lib/include (ala /lib/modules) is probably the best one but it
means dropping approxmiately 4 megabytes into /lib, which might cause
some problems for some partitioning schemes.
My external kernel module packages use a define at the top of a makefile
as well (and currently defaulted to /usr/src/linux; I can change that).
This is fine for me, but I'd like to be able to support users that don't
necessarily know how to edit Makefiles. I'd like for them to be able to
type "make" and "make install" as root, and that's about it. In order
to do this, we need some kind of convention. Covnentions are Good
Things.
- Ted
Jamie Lokier
> standardized. It could be any one of
>
> /usr/src/linux
> /lib/include/`uname -r`
> ../linux
>
> (the last requires that pcmcia and Rocketport packages have to be in the
> same top-level directory as the kernel source tree).
>
> I could live with any of these; as long as we all can agree on a single
> convention, so that default is always right. If you don't like
> /usr/src/linux because of the past history, and how user-mode packages
> are using it incorrectly, let's create a new convention. I personally
> think /lib/include (ala /lib/modules) is probably the best one but it
> means dropping approxmiately 4 megabytes into /lib, which might cause
> some problems for some partitioning schemes.
Please, if it goes in /lib then /lib/modules/include.
But instead, how about a script: /lib/modules/VERSION/compile-module.
The script would know where to find the kernel headers. That could be
/lib/modules/include for distributions, and /my/kernel/tree/include for
folks who used `make modules_install' recently.
Even better, the script has the ability to add multiple include paths,
so that you get the right SMP/UP-specific config.h but don't have to
have two copies of the unchanged headers.
Distributions can change the script if they want to control where the
relevant headers are installed. They'd probably set the location to
/usr/src/linux-DISTVERSION/include/linux or
/lib/modules/DISTVERSION/include according to their preference. And
they might want to do the subtarget-specific config.h thing.
Here's a first stab at one a distro might use:
#!/bin/sh
KERNEL_CONFIG=/lib/modules/2.2.14-12/include
KERNEL_HEADERS=/usr/src/linux-2.2.14/include
gcc -O2 -I$KERNEL_CONFIG_HEADERS -I$KERNEL_HEADERS -c "$@" ;;
And one installed by doing `make modules_install' in /home/jamie/kernel/v2.4
#!/bin/sh
gcc -O2 -I/home/jamie/kernel/v2.4 -c "$@" ;;
You get the idea,
enjoy,
-- Jamie
Christoph Hellwig
> /lib/include and /lib/include/`uname -r`, if we all can agree on it as a
> standard, is as good as any.
>
> (Note that's not just the /lib/include/linux we would need symlinked; we
> would also need /lib/include/asm as well.)
It's yust plain ugly.
a) they dont't have to be in the root filesystem
b) headers in <foo>/lib are plain ugly, too
/usr/include/$(uname -a)/$(uname -r)
would be much better an support propoer cross-compiling, too.
Christoph
--
Always remember that you are unique. Just like everyone else.
Jamie Lokier
> It still means that the kernel header files would have to be source-level
> backwards compatible forever. Something which hasn't been true in the
> past, and I don't want to be true in the future either. It's been damn
> painful to not be able to clean stuff up because some user-level setup is
> wrong.
If drop source compatibility with user space, you end up with
user/kernel API files referring to <asm/types.h> (at best).
That works fine but your suggestion to copy definitions into
applications is then ever more messy. All the basic types (`u32' etc.)
are wrong. So a straight cut and paste will not always work.
-- Jamie
Thomas Molina
> I'd really, really, like some kind of convention that could be
> standardized. It could be any one of
>
> /usr/src/linux
> /lib/include/`uname -r`
> ../linux
>
> (the last requires that pcmcia and Rocketport packages have to be in the
> same top-level directory as the kernel source tree).
>
> I could live with any of these; as long as we all can agree on a single
> convention, so that default is always right. If you don't like
> /usr/src/linux because of the past history, and how user-mode packages
> are using it incorrectly, let's create a new convention. I personally
> think /lib/include (ala /lib/modules) is probably the best one but it
> means dropping approxmiately 4 megabytes into /lib, which might cause
> some problems for some partitioning schemes.
IMHO, if we're going to "standardize" a place to put kernel sources I
really dislike /lib/<anything>. My own preference would be
/usr/local/linux. Linus doesn't like /usr/src/linux so that's probably
dead. /lib doesn't seem like the right place; /usr/local looks like the
best fit for a standard place.
Linus Torvalds
On Thu, 27 Jul 2000, Alan Cox wrote:
>
> Symlinks are wonderful things
>
> /lib/modules/2.2.14/build
I like this one. It puts the thing in the same tree as the modules
themselves, so it's self-contained. Let's _document_ it as a symlink, and
make "make modules_install" do that part too (I don't use modules so I'd
rather somebody else sent me the tested - likely one-liner - patch to do
this).
Linus
David Lombard
>
> On Thu, Jul 27, 2000 at 12:18:42PM -0400, Theodore Y. Ts'o wrote:
> > /lib/include and /lib/include/`uname -r`, if we all can agree on it as a
> > standard, is as good as any.
> >
> > (Note that's not just the /lib/include/linux we would need symlinked; we
> > would also need /lib/include/asm as well.)
>
> It's yust plain ugly.
> a) they dont't have to be in the root filesystem
> b) headers in <foo>/lib are plain ugly, too
>
> /usr/include/$(uname -a)/$(uname -r)
>
> would be much better an support propoer cross-compiling, too.
I hope you don't really mean $(uname -a)! Along with its redundancy
w.r.t. $(uname -r), it's needlessly specific and awful for parsing by
the shell. Perhaps you meant the kernel architecture name, which is not
available from uname(1).
It would be great if people creating external kernel modules could do
something like:
a) assume their module directory is in the kernel's root directory and
use relative paths.
or
b) use a hand-edited define that specifies the location of the kernel's
root directory (as suggested by Theodore).
It would be trivial to set this up for the newbie that can't deal with
the concepts. The rest of us would just do the Right Thing.
--
David N. Lombard
MSC.Software
Christoph Hellwig
> Christoph Hellwig wrote:
> >
> > On Thu, Jul 27, 2000 at 12:18:42PM -0400, Theodore Y. Ts'o wrote:
> > > /lib/include and /lib/include/`uname -r`, if we all can agree on it as a
> > > standard, is as good as any.
> > >
> > > (Note that's not just the /lib/include/linux we would need symlinked; we
> > > would also need /lib/include/asm as well.)
> >
> > It's yust plain ugly.
> > a) they dont't have to be in the root filesystem
> > b) headers in <foo>/lib are plain ugly, too
> >
> > /usr/include/$(uname -a)/$(uname -r)
> >
> > would be much better an support propoer cross-compiling, too.
>
> I hope you don't really mean $(uname -a)! Along with its redundancy
> w.r.t. $(uname -r), it's needlessly specific and awful for parsing by
> the shell. Perhaps you meant the kernel architecture name, which is not
> available from uname(1).
I meant uname -m (utsname->machine).
> It would be great if people creating external kernel modules could do
> something like:
> a) assume their module directory is in the kernel's root directory and
> use relative paths.
hmm looks interesting.
Christoph
--
Always remember that you are unique. Just like everyone else.
-
Christer Weinigel
> ../linux
I really like this one, I work a lot with embedded systems and I've
patched most of my development trees to use this convention. It means
that I can just check out my CVS tree and get identical binaries
(assuming the same compilers are used) anyway.
For example, this is how the top directory looks for a small system
using a Disk On Chip (DOC) flash and a PCMCIA controller:
bash$ ls /export/project:
CVS/ flash_doc/ pcmcia_cs/
Makefile linux/
And then the Makefile for the DOC looks like this, the TOPDIR define
is the important one, and to get the right compile options I'm using a
trick I think I've learned from the linux-mtd package:
===
# Makefile for a block device driver
# for the DiskOnChip flash module from M-Systems
#
# Copyright (C) 1998 IGEL GmbH
ifndef TOPDIR
TOPDIR:=$(shell cd ../linux && pwd)
endif
all:
make -C $(TOPDIR) SUBDIRS=`pwd` modules
clean:
rm -f *.o .*.flags
O_TARGET := fl.o
O_OBJS := flobj.o fldrvlnx.o
M_OBJS = $(O_TARGET)
MOD_LIST_NAME := NO_MODULES
fl.o: flobj.o
flobj.o: flobj.obj
rm -f flobj.o
cat flobj.obj >flobj.o
# Real actions are started from Rules.make
include $(TOPDIR)/Rules.make
===
So for a naive user who just wants to compile a module on his RedHat
system, tell him to unpack the module into /usr/src and assuming that
/usr/src/linux contains the current kernel source it'll just work.
For those who want to do special tricks it's always possible to do a:
TOPDIR=/usr/src/linux-2.2.17pre6 make
to use a specific kernel.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Jamie Lokier
> + rm -f $$MODLIB/build; \
> + ln -s `pwd` $$MODLIB/build; \
If $$MODLIB already exists and is a directory, you'll be creating a
link inside that directory which is probably not what you want.
Perhaps:
test -e $$MODLIB/build || ln -s `pwd` $$MODLIB/build
-- Jamie
Theodore Y. Ts'o
From: Jamie Lokier <l...@tantalophile.demon.co.uk>
Theodore Y. Ts'o wrote:
> + mkdir -p $$MODLIB; \
> + rm -f $$MODLIB/build; \
> + ln -s `pwd` $$MODLIB/build; \
If $$MODLIB already exists and is a directory, you'll be creating a
link inside that directory which is probably not what you want.
Perhaps:
test -e $$MODLIB/build || ln -s `pwd` $$MODLIB/build
Umm, did you notice the "rm -f" command before the "ln -s"?
This was to take care of the case where $$MODLIB/build exists, but
doesn't (necessarily) point to the right place. In your suggested case,
if $$MODLIB/build is present by points to the wrong location, it won't
get fixed.
- Ted
Linus Torvalds
On Thu, 27 Jul 2000, Theodore Y. Ts'o wrote:
>
> You asked for it, you got it.....
Ok. I changed the `pwd` to $TOPDIR, as that's what we use everywhere
else.. Objections?
Linus
Theodore Y. Ts'o
From: Jamie Lokier <l...@tantalophile.demon.co.uk>
Yes. That won't delete a *directory*.
If someone puts a directory there, deleting it via "rm -rf" is probably
the wrong thing. They're stupid, but they don't deserve to be punished
that badly. :-)
I'm not convinced the test -e test is worth it; creating a symlink in
the directory if the directory is there isn't going to be the end of the
world. I suppose the next time we do the build the make install will
blow out, but that can be easily fixed by making the ln command use
"ln -sf". We're arguing over niggling details, though....
If Linus wants to make the ln command use "ln -sf", that's great. If
not, it's not the end of the world...
- Ted
Theodore Y. Ts'o
From: Linus Torvalds <torv...@transmeta.com>
I like this one. It puts the thing in the same tree as the modules
themselves, so it's self-contained. Let's _document_ it as a symlink, and
make "make modules_install" do that part too (I don't use modules so I'd
rather somebody else sent me the tested - likely one-liner - patch to do
this).
You asked for it, you got it.....
- Ted
P.S. Vendors should test this against their kernel packaging tools,
which tend to do all sorts of non-standard stuff because they try to
build build multiple kernels and multiple sets of modules from a single
kernel source tree.
Patch generated: on Thu Jul 27 15:54:21 EDT 2000 by ty...@snap.thunk.org
against Linux version 2.4.0test5-pre5
===================================================================
RCS file: RCS/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- Makefile 2000/07/27 19:44:54 1.1
+++ Makefile 2000/07/27 19:51:12
@@ -306,13 +306,15 @@
modules_install:
@( \
MODLIB=$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE); \
+ mkdir -p $$MODLIB; \
+ rm -f $$MODLIB/build; \
+ ln -s `pwd` $$MODLIB/build; \
cd modules; \
MODULES=""; \
inst_mod() { These="`cat $$1`"; MODULES="$$MODULES $$These"; \
mkdir -p $$MODLIB/$$2; cp $$These $$MODLIB/$$2; \
echo Installing modules under $$MODLIB/$$2; \
}; \
- mkdir -p $$MODLIB; \
\
if [ -f BLOCK_MODULES ]; then inst_mod BLOCK_MODULES block; fi; \
if [ -f NET_MODULES ]; then inst_mod NET_MODULES net; fi; \
Christoph Hellwig
>
>
> On Thu, 27 Jul 2000, Theodore Y. Ts'o wrote:
> >
>
> else.. Objections?
Now that we have a 'non-module' object in /lib/modules, we could simply
copy System.map and the bzImage/vmlinux there and rename it to /kernel ...
Christoph
--
Always remember that you are unique. Just like everyone else.
-
Theodore Y. Ts'o
From: Christoph Hellwig <h...@caldera.de>
> Ok. I changed the `pwd` to $TOPDIR, as that's what we use everywhere
> else.. Objections?
Now that we have a 'non-module' object in /lib/modules, we could simply
copy System.map and the bzImage/vmlinux there and rename it to /kernel ...
That certainly makes a lot of sense; I've alwyas thought it was a bit
odd that some stuff was in /lib/modules and Systemp.map and bzImage are
stored in /boot. My guess is this is because Linus doesn't use modules,
so he doesn't see this particular aesthetic fault. :-)
I'm not entirely sure that now is the best time to make such a change,
but it does make a certain amount of sense.
- Ted
Jamie Lokier
> > + rm -f $$MODLIB/build; \
> > + ln -s `pwd` $$MODLIB/build; \
>
> link inside that directory which is probably not what you want.
> Perhaps:
>
> test -e $$MODLIB/build || ln -s `pwd` $$MODLIB/build
>
> Umm, did you notice the "rm -f" command before the "ln -s"?
Yes. That won't delete a *directory*.
> This was to take care of the case where $$MODLIB/build exists, but
> doesn't (necessarily) point to the right place. In your suggested case,
> if $$MODLIB/build is present by points to the wrong location, it won't
> get fixed.
My line is to replace only your last line. The rm -f should remain.
The "test -e" is in case $$MODLIB/build is a real directory, as opposed
to a symbolic link.
You might consider "rm -rf" for the second line instead.
-- Jamie
Russell King
> On Thu, 27 Jul 2000, Alan Cox wrote:
> > Symlinks are wonderful things
> >
> > /lib/modules/2.2.14/build
>
> themselves, so it's self-contained. Let's _document_ it as a symlink, and
> make "make modules_install" do that part too (I don't use modules so I'd
> rather somebody else sent me the tested - likely one-liner - patch to do
> this).
Let's think about this a little more carefully. IMHO, making
"modules_install" is the wrong place to do this:
1. When we haven't compiled any modules, we're not going to make
modules_install in addition to make install. Therefore this
link will not be set up.
2. What if the machine you're making modules_install on isn't the
machine that you're compiling other kernel modules packages on?
In this case, the compilation machine has no sight of the
symlink.
However, its fine for your single-box only setup where your kernel is
compiled on the same machine that its run on.
Or am I missing something fundamental here?
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King r...@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
win...@t1.ctrl-c.liu.se
>That certainly makes a lot of sense; I've alwyas thought it was a bit
>odd that some stuff was in /lib/modules and Systemp.map and bzImage are
>stored in /boot. My guess is this is because Linus doesn't use modules,
>so he doesn't see this particular aesthetic fault. :-)
There is one very good reason for putting the bzImage in /boot,
older BIOS:es have trouble with cylinders >1024 so I've almost
always but /boot on its own partition below 1024 cylinders and
have made it as small as possible, so even putting System.map
there is a mistake really, so I'd rather se System.map in
/lib/modules/`uname -r`.
/Christer
--
"Just how much can I get away with and still go to heaven?"
-
Johan Kullstam
> Date: Thu, 27 Jul 2000 23:03:40 +0200
> From: Christoph Hellwig <h...@caldera.de>
>
> > Ok. I changed the `pwd` to $TOPDIR, as that's what we use everywhere
> > else.. Objections?
>
> Now that we have a 'non-module' object in /lib/modules, we could simply
> copy System.map and the bzImage/vmlinux there and rename it to /kernel ...
>
> That certainly makes a lot of sense; I've alwyas thought it was a bit
> odd that some stuff was in /lib/modules and Systemp.map and bzImage are
> stored in /boot. My guess is this is because Linus doesn't use modules,
> so he doesn't see this particular aesthetic fault. :-)
having just yesterday run afoul of this, i second this sentiment. i
got a new faster hard disk and i copied the root system over to it.
then i built a new kernel. unfortunately, i botched my lilo config
and specified the wrong root partition (no biggie, i had good config
entries). when i booted, my modules were nowhere to be found (well,
they were on the other parition, so modutiles and various scripts
didn't find them...).
i think keeping the whole kernel, system.map and modules in one dir
tree would be better. the current system strikes me as a gratuitous
spreading of stuff all over creation. why isn't everything to do with
a kernel installation kept in one place?
1) stick the image, map ( initial ramdisks &c) into
/boot/$(uname -r)
2) put modules in /boot/$(uname -r)/modules instead of
/lib/modules/$(uname -r)
so for 2.2.17pre13 you'd have
/boot/2.2.17pre13/bzImage
/boot/2.2.17pre13/System.map
/boot/2.2.17pre13/modules/....
whether you use modules or not, i think it helps to bundle the image
and map and leave the filenames alone.
if you want a kernel include, make that dir/symlink
/boot/$(uname -r)/include
i'd be wanting to increase my /boot partition from 15MB to perhaps
20-30MB, but that's just small potatos.
> I'm not entirely sure that now is the best time to make such a change,
> but it does make a certain amount of sense.
it's only a cosmetic re-arrangement and wouldn't affect the kernel
itself. otoh modutils and a few scripts depend upon the historical
placement of the modules. i am not sure how painful that would be to
change. i think a symlink
/lib/modules/$(uname -r) -> /boot/$(uname -r)/modules
would take care of most of it, no?
yet another little request -- can we number the new kernel with pre
patch too? i am using 2.4.0-test5-pre5 but the -pre5 is gone from
uname -r. i'd like to see -pre5 added to extraversion like the -acXX
stuff was.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
H. Peter Anvin
By author: Thomas Molina <tmo...@home.com>
In newsgroup: linux.dev.kernel
>
> IMHO, if we're going to "standardize" a place to put kernel sources I
> really dislike /lib/<anything>. My own preference would be
> /usr/local/linux. Linus doesn't like /usr/src/linux so that's probably
> dead. /lib doesn't seem like the right place; /usr/local looks like the
> best fit for a standard place.
>
You're kidding, right? /usr/local is BY DEFINITION full of
non-standard stuff. Read the FHS (http://www.pathname.com/).
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
H. Peter Anvin
By author: win...@t1.ctrl-c.liu.se
In newsgroup: linux.dev.kernel
> >odd that some stuff was in /lib/modules and Systemp.map and bzImage are
> >stored in /boot. My guess is this is because Linus doesn't use modules,
> >so he doesn't see this particular aesthetic fault. :-)
>
> older BIOS:es have trouble with cylinders >1024 so I've almost
> always but /boot on its own partition below 1024 cylinders and
> have made it as small as possible, so even putting System.map
> there is a mistake really, so I'd rather se System.map in
> /lib/modules/`uname -r`.
>
bzImage needs to be in /boot. System.map and vmlinux does *NOT* need
to be in /boot. Recent modutils support storing them in
/lib/modules/`uname -r`/kernel.
Alan Cox
> standardized. It could be any one of
<Vendor hat on>
Ditto
> /usr/src/linux
> /lib/include/`uname -r`
> ../linux
>
> (the last requires that pcmcia and Rocketport packages have to be in the
> same top-level directory as the kernel source tree).
Submit something to the FHS ?
> think /lib/include (ala /lib/modules) is probably the best one but it
> means dropping approxmiately 4 megabytes into /lib, which might cause
> some problems for some partitioning schemes.
Symlinks are wonderful things
/lib/modules/2.2.14/build
neither needs to be a source tree in full nor a copy. In fact its ideal since
make modules_install will know enough to make the link so the link will
defacto get put in the right place when people install new kernels. Self
updating to new features is good.
Alan
Brian Pomerantz
>
> Please, if it goes in /lib then /lib/modules/include.
>
> But instead, how about a script: /lib/modules/VERSION/compile-module.
> The script would know where to find the kernel headers. That could be
> /lib/modules/include for distributions, and /my/kernel/tree/include for
> folks who used `make modules_install' recently.
>
> Even better, the script has the ability to add multiple include paths,
> so that you get the right SMP/UP-specific config.h but don't have to
> have two copies of the unchanged headers.
>
> Distributions can change the script if they want to control where the
> relevant headers are installed. They'd probably set the location to
> /usr/src/linux-DISTVERSION/include/linux or
> /lib/modules/DISTVERSION/include according to their preference. And
> they might want to do the subtarget-specific config.h thing.
>
> Here's a first stab at one a distro might use:
>
> #!/bin/sh
> KERNEL_CONFIG=/lib/modules/2.2.14-12/include
> KERNEL_HEADERS=/usr/src/linux-2.2.14/include
> gcc -O2 -I$KERNEL_CONFIG_HEADERS -I$KERNEL_HEADERS -c "$@" ;;
>
> And one installed by doing `make modules_install' in /home/jamie/kernel/v2.4
>
> #!/bin/sh
> gcc -O2 -I/home/jamie/kernel/v2.4 -c "$@" ;;
>
I kind of like the way the gtk and gnome packages have a script that
can be run to get CFLAGS. You could have a kernel script that gets
generated and installed when you do a 'make install' or
'make modules_install' which would spit out the correct CFLAGS for the
include files. It could be as easy as:
#!/bin/sh
echo "-I/home/bapper/src/linux-2.4.0/include"
That way any Makefile can run the script on the command line for gcc:
gcc -O2 `/lib/modules/kernel-includes` -c foo.c
It could take some arguments to echo other flags such as CFLAGS the
kernel uses to compile modules. And of course, this would have the
added bonus of defining the architecture and optimizations that were
used in the compiling of the kernel.
BAPper
Jamie Lokier
> package; remember? The one which you recommended distro's should use
> because the 2.4 PCMCIA code wasn't quite up to snuff yet.
Let's try to keep the two dicsussions separate. The problems with
compiling modules are important, but quite different to the problem of
user-space applications.
Linus' `grep O_NOFOLLOW' was about a user-space application (treescan).
-- Jamie
Linus Torvalds
On Thu, 27 Jul 2000, Theodore Y. Ts'o wrote:
>
> Linus,
>
> I'm talking about kernel modules. Like the external PCMCIA
> package; remember? The one which you recommended distro's should use
> because the 2.4 PCMCIA code wasn't quite up to snuff yet.
Oh.
Ok. That one I've actually never had any problems with, even though _I_
haven't used /usr/src/linux in a long time.
I think it asks the user where the kernel tree is when it does its
configuration. It's not the only question either, so it doesn't sound like
a problem (maybe it _defaults_ to /usr/src/linux, and that may be fine:
it's likely to be the kernel the distribution came with, so..
> It would be nice, however, if there was a painless way to
> compile such external kernel modules so they easily work with whatever
> kernels happens to be on the machine.
You're right, right now kernel modules need some way of specifying where
the kernel is. I've always just had a define at the top of a makefile that
the user actually had to edit by hand (this was how early USB-development
was done, for example). Not very pretty, I guess. But at least it doesn't
screw the "normal" user packages.
Linus
Ulrich Drepper
> I expect that library versions and compiler versions should matter to
> compiling programs. But I do _not_ want kernel versions to do that. It's
> already painful for people that you have to have the right library
> version. I'd _hate_ to see source code that says "requires kernel 2.3.99
> or higher sources in /usr/src/linux" in addition to saying "needs
> glibc-2.1.2 or newer for threading reasons".
I cannot except any of your accusations. Your style of development
these sudden, unplanned changes is what makes it necessary to not add
all the content to the libc headers. In addition, and I repeat this
probably for the thousands time, where the f*ck is the sysconf()
functions which is so very much needed?
Until you provide solutions for this you cannot expect others to do
more work. I would have to release a new glibc version every week
since something changed and somebody will run into the problems. And
no, your argument that the people who are doing such low-level work
should know what to do doesn't cut. Those people might know, but what
they produce and ideally distribute in source form has to be compiled
by the clueless. They don't know how to change their system (if they
even have the permission) and hardcoding new values is also out of
question.
Maybe you should spent some time thinking how *you* can improve the
process of using more recent kernels before complaining about others.
The first and obvious thing is to implement __sys_sysconf (maybe do it
on top of sysctl, I don't care).
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
Jamie Lokier
relevant stuff in header files from the kernel-only internals.
I mean creating a <linux/api/ppdev.h> etc. for all the ioctls and
user-visible structure definitions. Leave the _kernel_ stuff in linux/.
Applications that use a feature should still make a copy of the
appropriate header file. (But they don't have to, at least when
throwing something together locally). At least they could just copy
files, instead of extracting individual definitions and having to change
the references to fundamental types.
-- Jamie
Theodore Y. Ts'o
From: Linus Torvalds <torv...@transmeta.com>
No. You really miss the point. That _still_ makes the program depend
differently on which kernel happens to be on which machine. Which is so
obviously wrong that I don't understand how anybody can accept it.
Linus,
I'm talking about kernel modules. Like the external PCMCIA
package; remember? The one which you recommended distro's should use
because the 2.4 PCMCIA code wasn't quite up to snuff yet.
Kernel modules *inherently* depends on which kernel happens to
be running on which machine. We can't change that, because we don't
want to lock down kernel interfaces.
It would be nice, however, if there was a painless way to
compile such external kernel modules so they easily work with whatever
kernels happens to be on the machine.
I accept your arguments that user-mode programs shouldn't depend
on the kernel which you happen to be compiling on. But this simply
doesn't work for kernel modules.
- Ted
Thomas Molina
> Followup to: <Pine.LNX.4.10.10007...@wr5z.localdomain>
> By author: Thomas Molina <tmo...@home.com>
> In newsgroup: linux.dev.kernel
> >
> > IMHO, if we're going to "standardize" a place to put kernel sources I
> > really dislike /lib/<anything>. My own preference would be
> > /usr/local/linux. Linus doesn't like /usr/src/linux so that's probably
> > dead. /lib doesn't seem like the right place; /usr/local looks like the
> > best fit for a standard place.
> >
>
> You're kidding, right? /usr/local is BY DEFINITION full of
> non-standard stuff. Read the FHS (http://www.pathname.com/).
No I'm not kidding. Based on some comments by Linus earlier, he is
advocating putting the kernel source tree out of the way of glibc and
other "standard" development tools. /usr/local seems a better fit to me
than /lib/modules. According to FHS /lib is for essential shared
libraries and kernel modules. It also says one of the uses of
/usr/local is for local source code. It's also one of the few places
which shouldn't get clobbered in a system software upgrade.
It was an opinion; I'm expressing my 'druthers, if you will. I know
others don't agree. I see where it looks as if Linus is leaning towards
/lib/modules anyway, so I'll adapt. Or I'll be contrary and make
appropriate local changes in the source code. As long as Linus keeps it
as a self-contained entity it won't matter anyway.
Drew Sanford
>
> Date: 27 Jul 2000 00:39:51 -0700
>
> I would suggest that people who compile new kernels should:
>
> - NOT do so in /usr/src. Leave whatever kernel (probably only the
> header files) that the distribution came with there, but don't touch
> it.
>
> - compile the kernel in their own home directory, as their very own
> selves. No need to be root to compile the kernel. You need to be root
> to _install_ the kernel, but that's different.
>
> - not have a single symbolic link in sight (except the one that the
> kernel build itself sets up, namely the "linux/include/asm" symlink
> that is only used for the internal kernel compile itself)
>
> May I suggest one slight change to this list? /usr/src/linux should be
> a symlink to the header files of whatever kernel is being booted by
> default. So you can compile your own kernel in your own home directory,
> but when you install your own kernel as the default boot kernel,
> /usr/src/linux should point to the header files of that kernel. As you
> say, it requres root to _install_ your own kernel, and that point, you
> can point /usr/src/linux at the appropriate place.
>
> This allows source packages which generate kernel modules which have to
> link against the current kernel ---- such as the external pcmcia driver,
> hich you've recommended that distro's use since 2.4's pcmcia support
> isn't quite up to snuff yet ---- be able to reliably find (or at least
> present the user with a sensible default) the header files of the kernel
> which is being installed as the default boot kernel.
>
> And this is actually what has been the suggested environment for at
> least the last five years. I don't know why the symlink business keeps
> on living on, like a bad zombie. Pretty much every distribution still
> has that broken symlink, and people still remember that the linux
> sources should go into "/usr/src/linux" even though that hasn't been
> true in a _loong_ time.
>
This is insanity. When I get a new kernel, I drop it straight into
/usr/src/linux. Compile away. I understand you're saying that this could
break some programs because because of changes in include file, but
thats what opensource is for. You notice something breaks, you patch it.
Try the fix on a machine still running an old kernel. Does it work? If
it compiles on both systems, submit the fix. Move on. Telling people to
change the way they've ALWAYS compiled kernels is not the answer.
Caution is good. People should have enough sense to back up old source
(unless you have your own personal T1 and its not a problem to download
a new kernel), but don't put safeguards that change 3 year old unix
standards into the system. Maybe I'm out of line and missed the point of
the conversation here. Pardon me if I am. If I'm not out of line, then
you know how I feel about the situation:).
--
Drew Sanford
Systems Administrator
Planetwe.com
Email: dr...@planetwe.com
Oliver Xymoron
> Date: Thu, 27 Jul 2000 23:03:40 +0200
> From: Christoph Hellwig <h...@caldera.de>
>
> > Ok. I changed the `pwd` to $TOPDIR, as that's what we use everywhere
> > else.. Objections?
>
> Now that we have a 'non-module' object in /lib/modules, we could simply
> copy System.map and the bzImage/vmlinux there and rename it to /kernel ...
>
> That certainly makes a lot of sense; I've alwyas thought it was a bit
> odd that some stuff was in /lib/modules and Systemp.map and bzImage are
> stored in /boot. My guess is this is because Linus doesn't use modules,
> so he doesn't see this particular aesthetic fault. :-)
The kernel image needs to be stored on a partition that can be reached by
the boot loader, unlike modules.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Alexander Viro
On Thu, 27 Jul 2000, Drew Sanford wrote:
> This is insanity. When I get a new kernel, I drop it straight into
> /usr/src/linux. Compile away. I understand you're saying that this could
Yes. And when you patch it? Or want to compare to trees? And build on
both? What, shuffle the things around? Thank you very much, I'll pass.
> break some programs because because of changes in include file, but
> thats what opensource is for. You notice something breaks, you patch it.
> Try the fix on a machine still running an old kernel. Does it work? If
> it compiles on both systems, submit the fix. Move on. Telling people to
> change the way they've ALWAYS compiled kernels is not the answer.
> Caution is good. People should have enough sense to back up old source
> (unless you have your own personal T1 and its not a problem to download
> a new kernel), but don't put safeguards that change 3 year old unix
Now, now - UNIX standards are way older than 3 years and always had been
very simple: system sources live under /sys.
Rogier Wolff
>
> the wrong thing. They're stupid, but they don't deserve to be punished
> that badly. :-)
Is for the same reason the
rm -f include/asm
in the build process not
rm -rf include/asm
???
I like to copy kernel-trees around with cp -lr, and normally end up
with a bogus inclue/asm directory, which needs to be rm -rf'ed before
I can properly build a kernel in the new tree...
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
Christoph Hellwig
> > Now that we have a 'non-module' object in /lib/modules, we could simply
> > copy System.map and the bzImage/vmlinux there and rename it to /kernel ...
> >
> > That certainly makes a lot of sense; I've alwyas thought it was a bit
> > odd that some stuff was in /lib/modules and Systemp.map and bzImage are
> > stored in /boot. My guess is this is because Linus doesn't use modules,
> > so he doesn't see this particular aesthetic fault. :-)
>
> The kernel image needs to be stored on a partition that can be reached by
> the boot loader, unlike modules.
And - what's the problem, you simply have /kernel as partitoon instead of /boot.
And sooner or later when we will (hopefully) get multiboot support in the
linux kernel the modules will be needed by the bootloader.
Christoph
--
Always remember that you are unique. Just like everyone else.
-
Andrey Savochkin
On Thu, Jul 27, 2000 at 08:15:18PM -0400, Johan Kullstam wrote:
> i think keeping the whole kernel, system.map and modules in one dir
> tree would be better. the current system strikes me as a gratuitous
> spreading of stuff all over creation. why isn't everything to do with
> a kernel installation kept in one place?
>
> 1) stick the image, map ( initial ramdisks &c) into
> /boot/$(uname -r)
> 2) put modules in /boot/$(uname -r)/modules instead of
> /lib/modules/$(uname -r)
>
> so for 2.2.17pre13 you'd have
>
> /boot/2.2.17pre13/bzImage
> /boot/2.2.17pre13/System.map
> /boot/2.2.17pre13/modules/....
I've been using exactly this layout for years.
Moreover, sometimes I keep a lot of kernels of the same version with some
differences in the code, so I give the directories self-speaking names (not
just $(uname -r)) and never have chances to use wrong modules or System.map.
My $0.02
Andrey V.
Savochkin
Urban Widmark
> I like to copy kernel-trees around with cp -lr, and normally end up
> with a bogus inclue/asm directory, which needs to be rm -rf'ed before
> I can properly build a kernel in the new tree...
cp -al ?
(or cp -dpRl, but I'm too lazy to type and much less remember that)
symlinks will still be symlinks after the copy. cp -a may be specific to
gnu cp.
/Urban
David Howells
Why not /usr/modules or /usr/kernel for the stuff required to compile modules
(in other words stuff that the kernel doesn't actually use), for example:
/usr/modules/2.2.16/include/linux/*.h
/usr/modules/2.2.16/include/asm/*.h
/usr/modules/2.2.16/Rules.make
/usr/modules/2.2.16/.config
And /lib/modules or /boot/modules or /kernel/modules for the modules
themselves (ie. stuff the kernel does actually use directly).
Some further ideas:
- How about having a separate tarball on ftp.kernel.org that contains user
interface header files (independent of kernel version).
- How about putting all the runtime kernel stuff under one directory, merging
in /boot, /lib/modules, etc. and also moving the stuff that shouldn't
really be under /proc there as well:
/kernel/2.2.16/vmlinuz
/kernel/2.2.16/System.map
/kernel/2.2.16/modules/modules.dep
/kernel/2.2.16/modules/...
/kernel/proc/cmdline
/kernel/proc/cpuinfo
/kernel/proc/devices
/kernel/proc/dma
/kernel/proc/filesystems
/kernel/proc/sys/...
/kernel/proc/...
David Howells
Chris Meadors
> No I'm not kidding. Based on some comments by Linus earlier, he is
> advocating putting the kernel source tree out of the way of glibc and
> other "standard" development tools. /usr/local seems a better fit to me
> than /lib/modules. According to FHS /lib is for essential shared
> libraries and kernel modules. It also says one of the uses of
> /usr/local is for local source code. It's also one of the few places
> which shouldn't get clobbered in a system software upgrade.
FHS also says that a distro should ship with nothing in the /usr/local
tree.
But the FHS also says you can't have things like /usr/apache. But I find
that most useful, as deleting one directory removes all traces of the
program. Large packages that would normally end up all over the place can
be contained (like X, which FHS does allow to have its own place under
/usr).
> It was an opinion; I'm expressing my 'druthers, if you will. I know
> others don't agree. I see where it looks as if Linus is leaning towards
> /lib/modules anyway, so I'll adapt. Or I'll be contrary and make
> appropriate local changes in the source code. As long as Linus keeps it
> as a self-contained entity it won't matter anyway.
/lib/modules seems good enough. But as somone else said, it might make
more sence to be /lib/kernel. The one problem I see with this, is I
usually have a small(ish) root partition. On any installation I've done
/lib has never had its own partition. And on most, the root partition
hasn't been big enough to hold an unpacked kernel tree.
--
Two penguins were walking on an iceburg. The first one said to the
second, "you look like you are wearing a tuxedo." The second one said,
"I might be..."
--David Lynch, Twin Peaks
Russell King
> Why not /usr/modules or /usr/kernel for the stuff required to compile modules
> (in other words stuff that the kernel doesn't actually use), for example:
All these discussions about moving stuff to /usr are forgetting one
fundamental point in the FHS - /usr is NOT guaranteed to be mounted
at boot. In fact, /usr may very well be shared between machines.
Therefore, if you have the following situation:
/ = /dev/hda1
/usr = /dev/sda1
or even:
/ = /dev/hda1
/usr = /dev/md0
and you have your scsi driver (or raid subsystem) as a module, you need
/usr/modules to mount /usr, but you don't have /usr mounted because you
don't have the module... catch 22.
/ should contain everything you need to get the system up and running.
Not /usr. Therefore, modules must not be placed under /usr.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King r...@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
-
Theodore Y. Ts'o
From: Jesse Pollard <pol...@tomcat.admin.navo.hpc.mil>
How about being able to set the link at boot time too - this is for those
sites that have multiple kernels installed (for instance: old reliable,
current reliable, and test). Then each kernel could use different modules
selected at boot time.
If you know you can always find the the module files (or the header
files, now) by doing a /lib/modules/`uname -r`, why do you need to set a
link at boot time? It makes things a little faster, and perhaps a
little easier for some build scripts, but does it enough to make a
difference? insmod already knows how to deal with this, and it doesn't
seem to be any kind of major burden.
- Ted
Jesse Pollard
>
> > I'd really, really, like some kind of convention that could be
> > standardized. It could be any one of
>
> <Vendor hat on>
>
> Ditto
>
> > /usr/src/linux
> > /lib/include/`uname -r`
> > ../linux
> >
> > (the last requires that pcmcia and Rocketport packages have to be in the
> > same top-level directory as the kernel source tree).
>
> Submit something to the FHS ?
>
> > think /lib/include (ala /lib/modules) is probably the best one but it
> > means dropping approxmiately 4 megabytes into /lib, which might cause
> > some problems for some partitioning schemes.
>
> Symlinks are wonderful things
>
> /lib/modules/2.2.14/build
>
> neither needs to be a source tree in full nor a copy. In fact its ideal since
> make modules_install will know enough to make the link so the link will
> defacto get put in the right place when people install new kernels. Self
> updating to new features is good.
Just an additional thought..
How about being able to set the link at boot time too - this is for those
sites that have multiple kernels installed (for instance: old reliable,
current reliable, and test). Then each kernel could use different modules
selected at boot time.
This can also be extended to the limited number of applications that
may depend on a particular module version (initialization/table loading/
hardware configuration...) to be selected in a more OS version independant
manner.
I'm thinking of things like the RSBAC security modules and applications that
have to have different versions of the privileged programs depending on the
different versions of the kernel.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
Jesse Pollard
>
> Jesse Pollard wrote:
> > > /lib/modules/2.2.14/build
> >
> > Just an additional thought..
> >
> > How about being able to set the link at boot time too - this is for those
> > sites that have multiple kernels installed (for instance: old reliable,
> > current reliable, and test). Then each kernel could use different modules
> > selected at boot time.
>
> That's what the "2.2.14" is for. Whatever mechanism you use to select
> version-dependent modules at boot time, you use that to find the
> appropriate "build" link too.
Yes, but the definition of the LINK hasn't been specified yet -
something like the command
(cd /lib/modules; ln -s 2.2.14 boot)
would do, but that defines the link. The path to the appropriate modules
is would be /lib/modules/boot/module_name. It would appear to simplify
the loader a bit by not requiring it to retrieve the uname -r (or uname
-m, or ...) and add flexibility to it as well since the actual link
might be created by:
(cd /lib/modules; ln -s `uname -m`/`uname -r` boot)
That would allow for variations in the directory structure while maintaining
compatiblility for all module loaders/build procedures that would need it.
Khimenko Victor
> On Thu, 27 Jul 2000, Thomas Molina wrote:
>> No I'm not kidding. Based on some comments by Linus earlier, he is
>> advocating putting the kernel source tree out of the way of glibc and
>> other "standard" development tools. /usr/local seems a better fit to me
>> than /lib/modules. According to FHS /lib is for essential shared
>> libraries and kernel modules. It also says one of the uses of
>> /usr/local is for local source code. It's also one of the few places
>> which shouldn't get clobbered in a system software upgrade.
> FHS also says that a distro should ship with nothing in the /usr/local
> tree.
And I find it ridiculous. Yes, for FILES I agree - it's place to install
local files for system. But for directory stubs... Where the hell I must
put local perl packages ? I prefer /usr/local/lib/perl for architecture
specific-ones and /usr/local/share/perl . And I (as dstribuion creator)
even can configure perl to use this directories. But I CAN NOT (according
to FHS) create this directories. Gosh. So now I need to GUEES where I can
put my extension files in /usr/local (or just put system specific files for
perl, tcl, guile and so on in some other place in system - but where ?).
Looks like FHS was created without such packages in mind (even if they are
numerous - emacs, perl, tcl, python, guile, etc: all this packages can be
configured to use OS-specific files and system-specific files just like
C compiler, but FHS supports such thing only for C compiler). Still it's
not kernel problem.
> But the FHS also says you can't have things like /usr/apache. But I find
> that most useful, as deleting one directory removes all traces of the
> program.
Your packager should handle this. If it's not part of OS then it should be
installed in /opt - this part of FHS looks Ok.
> Large packages that would normally end up all over the place can
> be contained (like X, which FHS does allow to have its own place under
> /usr).
IMO the only reson to keep X in there is to make linux more like other unixes.
>> It was an opinion; I'm expressing my 'druthers, if you will. I know
>> others don't agree. I see where it looks as if Linus is leaning towards
>> /lib/modules anyway, so I'll adapt. Or I'll be contrary and make
>> appropriate local changes in the source code. As long as Linus keeps it
>> as a self-contained entity it won't matter anyway.
> /lib/modules seems good enough. But as somone else said, it might make
> more sence to be /lib/kernel. The one problem I see with this, is I
> usually have a small(ish) root partition. On any installation I've done
> /lib has never had its own partition.
It's usually not even possible: you need glibc for /sbin/init. It's why there
are exist /bin,/lib,/sbin and /usr/bin,/usr/lib,/usr/sbin : files in
/bin,/lib,/sbin are needed to support mounting of other parts of system so
you can not put then on separate partition.
> And on most, the root partition hasn't been big enough to hold an unpacked
> kernel tree.
Yeah, kernel source is usually bigger then contents of /bin,/lib,/sbin
(and /etc) combined.
Oliver Xymoron
> And - what's the problem, you simply have /kernel as partitoon instead
> of /boot. And sooner or later when we will (hopefully) get multiboot
> support in the linux kernel the modules will be needed by the
> bootloader.
We'd like to keep boot as small as possible. Boot might be a floppy or
flash while lib lives on your cluster's main file server. This is solvable
with the 2.4 multiple mount technology, but that same technology will soon
give us per-process namespaces so playing radically with the filesystem
standard in the interim is a wasted effort.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Peter Jones
> > FHS also says that a distro should ship with nothing in the /usr/local
> > tree.
>
> And I find it ridiculous. Yes, for FILES I agree - it's place to install
> local files for system. But for directory stubs... Where the hell I must
> put local perl packages ? I prefer /usr/local/lib/perl for architecture
> specific-ones and /usr/local/share/perl . And I (as dstribuion creator)
> even can configure perl to use this directories. But I CAN NOT (according
> to FHS) create this directories. Gosh. So now I need to GUEES where I can
You've missed the point of /usr/local . FHS says that a vendor can't put
things in /usr/local; not that a sysadmin can't. If a vendor is shipping
perl, /usr/lib/perl5 and /usr/bin/perl is _just fine_. By definition,
that _isn't_ local.
--
Peter
Al Gore saying he invented the internet is like me saying I invented
the exponential
-- Gordon Moore
Khimenko Victor
On Fri, 28 Jul 2000, Peter Jones wrote:
> On Fri, 28 Jul 2000, Khimenko Victor wrote:
>
> > > FHS also says that a distro should ship with nothing in the /usr/local
> > > tree.
> >
> > And I find it ridiculous. Yes, for FILES I agree - it's place to install
> > local files for system. But for directory stubs... Where the hell I must
> > put local perl packages ? I prefer /usr/local/lib/perl for architecture
> > specific-ones and /usr/local/share/perl . And I (as dstribuion creator)
> > even can configure perl to use this directories. But I CAN NOT (according
> > to FHS) create this directories. Gosh. So now I need to GUEES where I can
>
> You've missed the point of /usr/local . FHS says that a vendor can't put
> things in /usr/local; not that a sysadmin can't. If a vendor is shipping
> perl, /usr/lib/perl5 and /usr/bin/perl is _just fine_. By definition,
> that _isn't_ local.
>
You missed the point here. Yes, /usr/lib/perl is just fine. But what about
locally compiled modules ? You can download thing from CPAN, compile it
and install. It's simple: perl Makefile.PL ; make ; make install ...
It'll compile CPAN module and will install it ... where it'll install it ?
Currently it'll install it in /usr/lib/perl5/site_perl/i386-linux
(arch-dependant files) or in /usr/lib/perl5/site_perl
(non-arch-dependant files). Emacs will search for additional packages in
/usr/share/emacs/20.7/site-lisp (and /usr/share/emacs/site-lisp) and so on.
And sysadmin can not change it easily: you need to recompile perl, emacs
or tcl. So instead of SINGLE place where all local stuff is stored
(/usr/local) you have LOCAL stuff scattered all over /usr :-( For C
libraries problem is solved: you can put .h files in /usr/local/include
and libraries in /usr/local/lib an your system compiler can find all
local stuff there. For other packages FHS offer no solution :-((
H. Peter Anvin
> >
> > You missed the point here. Yes, /usr/lib/perl is just fine. But what
> > about locally compiled modules ? You can download thing from CPAN,
> > compile it and install. It's simple: perl Makefile.PL ; make ; make
> > install ... It'll compile CPAN module and will install it ... where
> > it'll install it ? Currently it'll install it in
> > /usr/lib/perl5/site_perl/i386-linux (arch-dependant files) or in
> > /usr/lib/perl5/site_perl (non-arch-dependant files). Emacs will search
> > for additional packages in /usr/share/emacs/20.7/site-lisp (and
> > /usr/share/emacs/site-lisp) and so on. And sysadmin can not change it
> > easily: you need to recompile perl, emacs or tcl.
>
Ever heard of "symlinks"?
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Peter Jones
> On Fri, 28 Jul 2000, Peter Jones wrote:
>
> > You've missed the point of /usr/local . FHS says that a vendor can't put
> > things in /usr/local; not that a sysadmin can't. If a vendor is shipping
> > perl, /usr/lib/perl5 and /usr/bin/perl is _just fine_. By definition,
> > that _isn't_ local.
>
> You missed the point here. Yes, /usr/lib/perl is just fine. But what
> about locally compiled modules ? You can download thing from CPAN,
> compile it and install. It's simple: perl Makefile.PL ; make ; make
> install ... It'll compile CPAN module and will install it ... where
> it'll install it ? Currently it'll install it in
> /usr/lib/perl5/site_perl/i386-linux (arch-dependant files) or in
> /usr/lib/perl5/site_perl (non-arch-dependant files). Emacs will search
> for additional packages in /usr/share/emacs/20.7/site-lisp (and
> /usr/share/emacs/site-lisp) and so on. And sysadmin can not change it
> easily: you need to recompile perl, emacs or tcl. So instead of SINGLE
> place where all local stuff is stored (/usr/local) you have LOCAL
> stuff scattered all over /usr :-( For C libraries problem is solved:
> you can put .h files in /usr/local/include and libraries in
> /usr/local/lib an your system compiler can find all local stuff there.
> For other packages FHS offer no solution :-((
Regardless, the pointing of perl (or any other program) at /usr/local/* is
_the sysadmin's responsibility_, not the distributor's. There isn't any
need for the packager of the distribution to point things at /usr/local;
and even if you _do_ insist (as a packager) to do this, then the (obvious)
solution is to make sure that perl doesn't complain if its "use lib" path
doesn't exist, and wait until you're actually building that CPAN module to
make the directory there.
This is really a non-problem.
--
Peter
"Sanity's just a one trick pony anyway. You only get one trick -- rational
thinking -- but when you're good and crazy, the sky's the limit!"
-- The Tick
H. Peter Anvin
> Yeah, of course. Just FHS closed this way as well. Yes, I (as distribution
> maker) can make /usr/lib/perl5/site_perl/i386-linux symlink to
> /usr/local/lib/perl but since
> -- cut --
> This directory should always be empty after first installing a
> FHS-compliant system. No exceptions to this rule should be made other
> than the listed directory stubs.
> -- cut --
> I (as distribution maker) can not create /usr/local/lib/perl directory.
> Thus perl's make install will mysteriously fail while trying to install
> stuff.
Thank God. /usr/local is often shared, quite possibly readonly, and if
distribution packages messed with this, it would be impossible to use
them.
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
H. Peter Anvin
>
> On Fri, 28 Jul 2000, H. Peter Anvin wrote:
>
> > Khimenko Victor wrote:
> >
> > > Yeah, of course. Just FHS closed this way as well. Yes, I (as distribution
> > > maker) can make /usr/lib/perl5/site_perl/i386-linux symlink to
> > > /usr/local/lib/perl but since
> > > -- cut --
> > > This directory should always be empty after first installing a
> > > FHS-compliant system. No exceptions to this rule should be made other
> > > than the listed directory stubs.
> > > -- cut --
> > > I (as distribution maker) can not create /usr/local/lib/perl directory.
> > > Thus perl's make install will mysteriously fail while trying to install
> > > stuff.
> >
> > Thank God. /usr/local is often shared, quite possibly readonly, and if
> > distribution packages messed with this, it would be impossible to use
> > them.
> >
> mounts not such a big problem:
> -- http://www.debian.org/doc/debian-policy/ch3.html#s3.1.2 --
It's breaks if the directory is shared but still read-write. Bad idea.
clubneon
> In article <Pine.LNX.4.21.0007...@rc.priv.hereintown.net>,
> Chris Meadors <club...@hereintown.net> wrote:
> >
> >But the FHS also says you can't have things like /usr/apache. But I find
> >that most useful, as deleting one directory removes all traces of the
> >program. Large packages that would normally end up all over the place can
> >be contained (like X, which FHS does allow to have its own place under
> >/usr).
>
> You can do that in /opt or /usr/local if you like.
Just because so many (2 or 3) people have mentioned this to me I'll reply
to it shortly.
The problem I have with /opt is I'm not used to it yet. I'd have to put
it on it's own partition just like /usr, /home, and /var. I don't have
any feeling for how big /opt should be and I usually totally just forget
about it.
I'm building a new system now, I'm going to attempt to make use of /opt
for larger, self-contained packages. BUT /opt is going to be a symlink to
/usr/local (take that FHS). At least now I'll get a little more used to
using /opt.
Boy, I can't think of one thing to say that'll make this relevent to the
kernel.
Chris Meadors (at home)
Stuart Lynne
Chris Meadors <club...@hereintown.net> wrote:
>
>> No I'm not kidding. Based on some comments by Linus earlier, he is
>> advocating putting the kernel source tree out of the way of glibc and
>> other "standard" development tools. /usr/local seems a better fit to me
>> than /lib/modules. According to FHS /lib is for essential shared
>> libraries and kernel modules. It also says one of the uses of
>> /usr/local is for local source code. It's also one of the few places
>> which shouldn't get clobbered in a system software upgrade.
>
>tree.
>
>that most useful, as deleting one directory removes all traces of the
>program. Large packages that would normally end up all over the place can
>be contained (like X, which FHS does allow to have its own place under
>/usr).
You can do that in /opt or /usr/local if you like.
>> It was an opinion; I'm expressing my 'druthers, if you will. I know
>> others don't agree. I see where it looks as if Linus is leaning towards
>> /lib/modules anyway, so I'll adapt. Or I'll be contrary and make
>> appropriate local changes in the source code. As long as Linus keeps it
>> as a self-contained entity it won't matter anyway.
>
>/lib/modules seems good enough. But as somone else said, it might make
>more sence to be /lib/kernel. The one problem I see with this, is I
>usually have a small(ish) root partition. On any installation I've done
>/lib has never had its own partition. And on most, the root partition
>hasn't been big enough to hold an unpacked kernel tree.
/lib/modules is probably the easiest place to get some agreement. The
contents of that directory is not specified as of FHS 2.1.
This discussion should probably be done on the FHS list so that the
results can written up in that document. It currently mandates that
(for example) /usr/include/linux points at /usr/src/linux/include/linux.
--
__O
Fireplug - a Lineo company _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <s...@fireplug.net> www.fireplug.net 604-461-7532
Mike Castle
> I've been using exactly this layout for years.
> Moreover, sometimes I keep a lot of kernels of the same version with some
> differences in the code, so I give the directories self-speaking names (not
> just $(uname -r)) and never have chances to use wrong modules or System.map.
I've been thinking about this for a while now. I'd love to be able to
build and distribute from a single point a variety of kernels/modules and
have things installed into various locations. Ie, I'd like to enhance the
KERNELRELEASE stuff to also include something like LOCALINFO.
I can't use EXTRAVERSION because it's often in use (ie, pre17).
mrc
--
Mike Castle Life is like a clock: You can work constantly
dal...@ix.netcom.com and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
Jamie Lokier
> > /lib/modules/2.2.14/build
>
> Just an additional thought..
>
> How about being able to set the link at boot time too - this is for those
> sites that have multiple kernels installed (for instance: old reliable,
> current reliable, and test). Then each kernel could use different modules
> selected at boot time.
That's what the "2.2.14" is for. Whatever mechanism you use to select
version-dependent modules at boot time, you use that to find the
appropriate "build" link too.
-- Jamie
Adam Sampson
> Is there some documentation file that I've not updated and that people
> are slavishly following outdated information in? I don't read the
> documentation myself, so I'd never notice ;)
Yes; the glibc installation instructions.
--
Adam Sampson
a...@gnu.org
Adam Sampson
> But instead, how about a script: /lib/modules/VERSION/compile-module.
> The script would know where to find the kernel headers. That could be
> /lib/modules/include for distributions, and /my/kernel/tree/include for
> folks who used `make modules_install' recently.
I'll second that suggestion. This kind of thing works very well indeed for
projects like Apache.
Khimenko Victor
On Fri, 28 Jul 2000, H. Peter Anvin wrote:
> Khimenko Victor wrote:
>
> > Yeah, of course. Just FHS closed this way as well. Yes, I (as distribution
> > maker) can make /usr/lib/perl5/site_perl/i386-linux symlink to
> > /usr/local/lib/perl but since
> > -- cut --
> > This directory should always be empty after first installing a
> > FHS-compliant system. No exceptions to this rule should be made other
> > than the listed directory stubs.
> > -- cut --
> > I (as distribution maker) can not create /usr/local/lib/perl directory.
> > Thus perl's make install will mysteriously fail while trying to install
> > stuff.
>
> Thank God. /usr/local is often shared, quite possibly readonly, and if
> distribution packages messed with this, it would be impossible to use
> them.
>
Deabin DOING it. And I have NO complains about such behaviour. Read-only
mounts not such a big problem:
-- http://www.debian.org/doc/debian-policy/ch3.html#s3.1.2 --
[skipped]
Since /usr/local may be mounted read-only from a remote server, these
directories have to be created and removed by the postinst and prerm
maintainer scripts. These scripts must not fail if either of these
operations fail. (In the future, it will be possible to tell dpkg not
to unpack files matching certain patterns, so that the directories can
be included in the .deb packages and system administrators who do not
wish these directories in /usr/local do not need to have them.)
For example, the emacs package will contain
mkdir -p /usr/local/lib/emacs/site-lisp || true
in the postinst script, and
rmdir /usr/local/lib/emacs/site-lisp && \
rmdir /usr/local/lib/emacs || \
true
in the prerm script.
If you do create a directory in /usr/local for local additions to a
package, you must ensure that settings in /usr/local take precedence
over the equivalents in /usr.
However, because '/usr/local' and its contents are for exclusive use
of the local administrator, a package must not rely on the presence or
absence of files or directories in '/usr/local' for normal operation.
-- cut --
It looks like MUCH better compromise then "do not play games with
/usr/local and let sysadmin make symlinks again and again (after each
upgrade)".
Khimenko Victor
On Fri, 28 Jul 2000, H. Peter Anvin wrote:
> Khimenko Victor wrote:
> >
> > On Fri, 28 Jul 2000, H. Peter Anvin wrote:
> >
> > > Khimenko Victor wrote:
> > >
> > > > Yeah, of course. Just FHS closed this way as well. Yes, I (as distribution
> > > > maker) can make /usr/lib/perl5/site_perl/i386-linux symlink to
> > > > /usr/local/lib/perl but since
> > > > -- cut --
> > > > This directory should always be empty after first installing a
> > > > FHS-compliant system. No exceptions to this rule should be made other
> > > > than the listed directory stubs.
> > > > -- cut --
> > > > I (as distribution maker) can not create /usr/local/lib/perl directory.
> > > > Thus perl's make install will mysteriously fail while trying to install
> > > > stuff.
> > >
> > > Thank God. /usr/local is often shared, quite possibly readonly, and if
> > > distribution packages messed with this, it would be impossible to use
> > > them.
> > >
> > Deabin DOING it. And I have NO complains about such behaviour. Read-only
> > mounts not such a big problem:
> > -- http://www.debian.org/doc/debian-policy/ch3.html#s3.1.2 --
>
> It's breaks if the directory is shared but still read-write. Bad idea.
>
Not exactly. Ones who were knowleadgeable enough to create shared
read-write /usr/local will know what to do (mkdir -p WILL NOT overwrite
files, WILL NOT change permissions, etc - and it created directory it can
be as easily removed) with it, ones who have simple configuration (and
it's MAJORITY) will not have headache (unlike manual symlink creation
after each upgrade choice).
"Simple things should be simple, complex things should be possible". You
proposal makes maintaining of simple systems significally harder while
giving only VERY marginal win for complex ones.
Khimenko Victor
On Fri, 28 Jul 2000, Peter Jones wrote:
> On Fri, 28 Jul 2000, Khimenko Victor wrote:
>
> > On Fri, 28 Jul 2000, Peter Jones wrote:
> >
> > > You've missed the point of /usr/local . FHS says that a vendor can't put
> > > things in /usr/local; not that a sysadmin can't. If a vendor is shipping
> > > perl, /usr/lib/perl5 and /usr/bin/perl is _just fine_. By definition,
> > > that _isn't_ local.
> >
> > You missed the point here. Yes, /usr/lib/perl is just fine. But what
> > about locally compiled modules ? You can download thing from CPAN,
> > compile it and install. It's simple: perl Makefile.PL ; make ; make
> > install ... It'll compile CPAN module and will install it ... where
> > it'll install it ? Currently it'll install it in
> > /usr/lib/perl5/site_perl/i386-linux (arch-dependant files) or in
> > /usr/lib/perl5/site_perl (non-arch-dependant files). Emacs will search
> > for additional packages in /usr/share/emacs/20.7/site-lisp (and
> > /usr/share/emacs/site-lisp) and so on. And sysadmin can not change it
> > easily: you need to recompile perl, emacs or tcl. So instead of SINGLE
> > place where all local stuff is stored (/usr/local) you have LOCAL
> > stuff scattered all over /usr :-( For C libraries problem is solved:
> > you can put .h files in /usr/local/include and libraries in
> > /usr/local/lib an your system compiler can find all local stuff there.
> > For other packages FHS offer no solution :-((
>
> Regardless, the pointing of perl (or any other program) at /usr/local/* is
> _the sysadmin's responsibility_, not the distributor's.
Debian policy say it's other way around ( see
http://www.debian.org/doc/debian-policy/ch3.html#s3.1.2 ) ... I think it's
correct: it's easy to understood that if you have /usr/local/share/emacs
directory that you can put files there. It MUCH harder to notice that
if you'll CREATE directory there and THEN put stuff in there emacs will
spot it.
> There isn't any need for the packager of the distribution to point
> things at /usr/local;
Yeah ? Where to point it then ?
> and even if you _do_ insist (as a packager) to do this, then the (obvious)
> solution is to make sure that perl doesn't complain if its "use lib" path
> doesn't exist, and wait until you're actually building that CPAN module to
> make the directory there.
>
Not all programs have such automagic installation mechanism in place. When
it's enough to put file in there it really looks like overkill to develop
one.
Khimenko Victor
On Fri, 28 Jul 2000, H. Peter Anvin wrote:
> Peter Jones wrote:
> > >
> > > You missed the point here. Yes, /usr/lib/perl is just fine. But what
> > > about locally compiled modules ? You can download thing from CPAN,
> > > compile it and install. It's simple: perl Makefile.PL ; make ; make
> > > install ... It'll compile CPAN module and will install it ... where
> > > it'll install it ? Currently it'll install it in
> > > /usr/lib/perl5/site_perl/i386-linux (arch-dependant files) or in
> > > /usr/lib/perl5/site_perl (non-arch-dependant files). Emacs will search
> > > for additional packages in /usr/share/emacs/20.7/site-lisp (and
> > > /usr/share/emacs/site-lisp) and so on. And sysadmin can not change it
> > > easily: you need to recompile perl, emacs or tcl.
> >
>
> Ever heard of "symlinks"?
>
Yeah, of course. Just FHS closed this way as well. Yes, I (as distribution
maker) can make /usr/lib/perl5/site_perl/i386-linux symlink to
/usr/local/lib/perl but since
-- cut --
This directory should always be empty after first installing a
FHS-compliant system. No exceptions to this rule should be made other
than the listed directory stubs.
-- cut --
I (as distribution maker) can not create /usr/local/lib/perl directory.
Thus perl's make install will mysteriously fail while trying to install
stuff. Or I (as sysadmin) must GUESS that I should create /usr/local/lib/perl
before using perl's `make install' ? Gosh. So much for FHS-compliance.
Or may be you can suggest some other clever way to solve this problem ?
P.S. May be I just poor in English and in fact creation of subdirectories
UNDER /usr/local (not IN /usr/local) is allowed ? At least it looks like
Debian mantainers think so:
-- cut --
3.1.2 Site-specific programs
As mandated by the FHS no package should place any files in
/usr/local, either by putting them in the file system archive to be
unpacked by dpkg or by manipulating them in their maintainer scripts.
However, the package should create empty directories below /usr/local
so that the system administrator knows where to place site-specific
files. These directories should be removed on package removal if they
are empty.
Note, that this applies only to directories below /usr/local, not in
/usr/local. The directory /usr/local itself may only contain the
sub-directories listed in FHS, section 4.6. However, you may create
directories below them as you wish. You may not remove any of the
directories listed in 4.6, even if you created them.
-- cut --
It this is so then it's Ok: there are really no need to put anything in
/usr/local itself and under /usr/local only empty directoryes for local
stuff are needed...
Looks like FHS wording is too vague in this place...
David Howells
> David Howells writes:
> > Why not /usr/modules or /usr/kernel for the stuff required to compile modules
> > (in other words stuff that the kernel doesn't actually use), for example:
>
> All these discussions about moving stuff to /usr are forgetting one
> fundamental point in the FHS - /usr is NOT guaranteed to be mounted
> at boot. In fact, /usr may very well be shared between machines.
You missed my point - put _compile_ time stuff under /usr/whatever and
_runtime_ stuff under /lib/modules or /kernel
David Howells
Stephen Harris
: And I find it ridiculous. Yes, for FILES I agree - it's place to install
: local files for system. But for directory stubs... Where the hell I must
: put local perl packages ? I prefer /usr/local/lib/perl for architecture
: specific-ones and /usr/local/share/perl . And I (as dstribuion creator)
: even can configure perl to use this directories. But I CAN NOT (according
: to FHS) create this directories. Gosh. So now I need to GUEES where I can
This is an old question and was hashed out many times on the original
FSSTND list (yikes, back in the early 90's!). If you are creating a general
purpose distribution, then these files are _not_ local to anything, so
/usr/local is trivially the wrong place. If you are creating a distribution
local to your company, then feel free to use /usr/local. If you are
automating an install for your environment, then feel free to use /usr/local.
Any distribution that uses /usr/local for general distribution is not FSSTND
(sorry, FHS) compliant.
It's very simple, really.
: Your packager should handle this. If it's not part of OS then it should be
: installed in /opt - this part of FHS looks Ok.
And this had the most arguments of all :-) Probably 60% of all traffic
was about this :-)
--
Stephen Harris
sw...@spuddy.mew.co.uk http://www.spuddy.org/
The truth is the truth, and opinion just opinion. But what is what?
My employer pays to ignore my opinions; you get to do it for free.
* Meeeeow ! Call Spud the Cat on > 01708 442043 < for free Usenet access *
Miquel van Smoorenburg
Adam Sampson <a...@gnu.org> wrote:
>On Thu, Jul 27, 2000 at 07:03:57PM +0200, Jamie Lokier wrote:
>> But instead, how about a script: /lib/modules/VERSION/compile-module.
>> The script would know where to find the kernel headers. That could be
>> /lib/modules/include for distributions, and /my/kernel/tree/include for
>> folks who used `make modules_install' recently.
>
>I'll second that suggestion. This kind of thing works very well indeed for
>projects like Apache.
It is indeed a very good idea. The script could just spit out the
CFLAGS used for kernel compilation like this:
#! /bin/sh
cat <<EOF
-D__KERNEL__ -I/usr/src/linux-2.2.15/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DUTS_MACHINE='"i386"'
EOF
Then a module Makefile would be as simple as
# Set KVER manually if you want to compile against another kernel version
KVER=$(shell uname -r)
CFLAGS=$(shell /lib/modules/$(KVER)/kernel-config)
module.o: module.c module.h
I've tried this, it works.
Mike.
--
Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.
Mike Galbraith
> On 31 Jul 2000, Kai Henningsen wrote:
>
> > pol...@tomcat.admin.navo.hpc.mil (Jesse Pollard) wrote on 27.07.00 in <2000072715...@tomcat.admin.navo.hpc.mil>:
> >
> > > Might I suggest creating a "/lib/include" that works something like
> > > the /lib/modules where the kernel name is used to generate the directory
> > > for the kernel include files?
> > >
> > > That way the "uname -r" command could be used to set a symbolic link
> > > to point to the correct include files at boot time (or install time).
> >
> > Correct for what?
> >
<snip>
> Why would anybody change this? I fear that this is another of those;
> "It doesn't have to be better, only different..." things that have
> been going around.
Well, I suspect that there is an issue for driver authors/maintainers,
but haven't figured out quite what that issue is. Why does it matter?
I really couldn't care less where headers officially live.. as long as
it's possiblle [preferably easy] to maintain them where _I_ want them.
(and that is nowhere near /)
-Mike
Miquel van Smoorenburg
Richard B. Johnson <ro...@chaos.analogic.com> wrote:
> /usr/include/linux and /usr/include/asm are symbolic links, referenced
>to /usr/src/linux, not a specific version. This makes changing kernel
>development versions a simple change of a single symbolic link.
No. Even Linus himself has been saying for years (and recently even
in this thread) that /usr/include/linux and /usr/include/asm should
NOT EVER be symlinks to /usr/src/linux
Everything in /usr/include belongs to and depends on glibc, not
the currently running kernel.
And if you want to compile modules and use /usr/include/linux for
the include files, what are you going to do about networking
modules that use include/net ? The one in the kernel source is
very, very different from the one in glibc .. so you have to compile
with -I/path/to/kernel/include _anyway_
You can't just use /usr/src/linux/include, what if you want to compile
against another kernel version? What if you are not root ?
The /lib/modules/version/ stuff is a good idea, but it should
contain a `kernel-config' script that outputs the complete CFLAGS
that the kernel was compiled with. Easy, simple, enduser friendly.
Mike.
--
Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.
-
H. Peter Anvin
By author: miq...@cistron.nl (Miquel van Smoorenburg)
In newsgroup: linux.dev.kernel
>
> No. Even Linus himself has been saying for years (and recently even
> in this thread) that /usr/include/linux and /usr/include/asm should
> NOT EVER be symlinks to /usr/src/linux
>
> Everything in /usr/include belongs to and depends on glibc, not
> the currently running kernel.
>
Unfortunately that doesn't work very well. For user-space daemons
which talk to Linux-specific kernel interfaces, such as automount, you
need both the glibc and the Linux kernel headers.
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
Miquel van Smoorenburg
>> No. Even Linus himself has been saying for years (and recently even
>> in this thread) that /usr/include/linux and /usr/include/asm should
>> NOT EVER be symlinks to /usr/src/linux
>
That is the problem. Linus has been saying that for years, but
as I said, for some reason people refuse to listen. You're proving
my point.
>In fact, the first trees that
>Linus made and distributed were done this way and have become the
>de-facto standard as a result of this.
Read <8lop07$2ee$1...@penguin.transmeta.com> in which Linus says:
>/usr/include/asm is a symlink to /usr/src/linux/include/asm, as in the
>original distribution but /usr/src/linux is a 2.4.0-testX tree.
>With a 2.2.X source tree, it does not produce any warning.
I've asked glibc maintainers to stop the symlink insanity for the last
few years now, but it doesn't seem to happen.
Basically, that symlink should not be a symlink. It's a symlink for
historical reasons, none of them very good any more (and haven't been
for a long time), and it's a disaster unless you want to be a C library
developer. Which not very many people want to be.
The fact is, that the header files should match the library you link
against, not the kernel you run on.
Also read <Pine.LNX.4.10.100072...@penguin.transmeta.com>
for more enlightenment. If you want to join a thread, please make sure
that you have read all messages in it.
Mike.
--
Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.
-
Richard B. Johnson
> In article >Pine.LNX.3.95.10007...@chaos.analogic.com>,
> Richard B. Johnson <ro...@chaos.analogic.com> wrote:
> > /usr/include/linux and /usr/include/asm are symbolic links, referenced
> >to /usr/src/linux, not a specific version. This makes changing kernel
> >development versions a simple change of a single symbolic link.
>
> No. Even Linus himself has been saying for years (and recently even
> in this thread) that /usr/include/linux and /usr/include/asm should
> NOT EVER be symlinks to /usr/src/linux
>
I don't think Linus said that at all. In fact, the first trees that
Linus made and distributed were done this way and have become the
de-facto standard as a result of this.
> Everything in /usr/include belongs to and depends on glibc, not
> the currently running kernel.
>
No. I have /usr/include/subdirectories which contain headers for X11, some
that contain headers for Motif, some that contain headers for pthreads,
bind-4.9.3, etc. These are not glibc headers.
You cannot decide that I can't keep these where they are.
Any portable code is not supposed to include non-portable headers.
This means that if your code does:
#include <linux/something.h>
it is not portable. If your portable code is written properly, the
presence of links to non-portable headers in /usr/include does nothing.
They are never referenced.
When you need to have current kernel headers referenced, your non-
portable code (like modules) specifically includes the linux headers.
This is now it's been done. I see no reason to change it.
> And if you want to compile modules and use /usr/include/linux for
> the include files, what are you going to do about networking
> modules that use include/net ? The one in the kernel source is
> very, very different from the one in glibc .. so you have to compile
> with -I/path/to/kernel/include _anyway_
>
> You can't just use /usr/src/linux/include, what if you want to compile
> against another kernel version? What if you are not root ?
>
We don't use /usr/src/linux/include. As stated, the include files
are referenced from /usr/include.
> The /lib/modules/version/ stuff is a good idea, but it should
> contain a `kernel-config' script that outputs the complete CFLAGS
> that the kernel was compiled with. Easy, simple, enduser friendly.
>
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
H. Peter Anvin
>
> In article <8m54u3$dh0$1...@cesium.transmeta.com> you h...@zytor.com wrote:
> >Let's get this straight: #include <linux/*> and #include <asm/*> are
> >*expected* to be the kernel headers. This is a completely different
> >issue from the fact that glibc headers shouldn't #include these
> >headers like libc5 did.
>
> And IMHO to be able to do this, one should have to provide an explicit
> -I/usr/src/my-kernel/linux/include, it should not be the default.
>
I disagree. It makes life far too painful for the end user, for really no gain.
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
H. Peter Anvin
> >> the currently running kernel.
> >
> >which talk to Linux-specific kernel interfaces, such as automount, you
> >need both the glibc and the Linux kernel headers.
>
> probably best off by using a talktokernel.c file that is
> compiled with -I/path/to/kernel/include while the rest of the
> daemon doesn't know about kernel internals.
>
> That could and perhaps should be fixed, but I think that is
> a different issue entirely.
>
For most kernel interface daemons, that is not an option. You need to
be able to translate (or just transfer information) between
glibc-provided and kernel-provided data structures, so you need to be
able to include all the datatypes.
Let's get this straight: #include <linux/*> and #include <asm/*> are
*expected* to be the kernel headers. This is a completely different
issue from the fact that glibc headers shouldn't #include these
headers like libc5 did.
-hpa
Mike Castle
> modules that use include/net ? The one in the kernel source is
> very, very different from the one in glibc .. so you have to compile
> with -I/path/to/kernel/include _anyway_
Maybe just make it mandatory that every time you upgrade the kernel, you
should rebuild the entire system.
mrc
--
Mike Castle Life is like a clock: You can work constantly
dal...@ix.netcom.com and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
-
Mike Castle
> Unfortunately that doesn't work very well. For user-space daemons
> which talk to Linux-specific kernel interfaces, such as automount, you
> need both the glibc and the Linux kernel headers.
Does this mean that automount has to be rebuilt for every kernel? And that
we should be running /lib/modules/`uname -r`/sbin/automount.
It's sounds like it's an awful lot like a loadable module in how tightly
it's tied to the kernel. And how a kernel change can break things
horribly. How you have to be built against the one you're going to run
against and not the one glibc was built against.
win...@t1.ctrl-c.liu.se
>*expected* to be the kernel headers. This is a completely different
>issue from the fact that glibc headers shouldn't #include these
>headers like libc5 did.
And IMHO to be able to do this, one should have to provide an explicit
-I/usr/src/my-kernel/linux/include, it should not be the default.
/Christer
--
"Just how much can I get away with and still go to heaven?"
win...@t1.ctrl-c.liu.se
>On Mon, Jul 31, 2000 at 03:13:55PM -0700, H. Peter Anvin wrote:
>> Unfortunately that doesn't work very well. For user-space daemons
>> which talk to Linux-specific kernel interfaces, such as automount, you
>> need both the glibc and the Linux kernel headers.
>
>Does this mean that automount has to be rebuilt for every kernel? And that
>we should be running /lib/modules/`uname -r`/sbin/automount.
>
>It's sounds like it's an awful lot like a loadable module in how tightly
>it's tied to the kernel. And how a kernel change can break things
>horribly. How you have to be built against the one you're going to run
>against and not the one glibc was built against.
It only means that the application will be built agains the kernel
_interface_ that was present in that version of the kernel. And
syscall/ioctl interfaces should never change, they can be added to,
and relly old depreciated interfaces can be removed, but they should
be stable for at least a few major kernel releases.
win...@t1.ctrl-c.liu.se
>win...@t1.ctrl-c.liu.se wrote:
>> And IMHO to be able to do this, one should have to provide an explicit
>> -I/usr/src/my-kernel/linux/include, it should not be the default.
>
The idea was to make a point, that #include <linux/xxx.h> really is
a kernel/kernel aware application thing only. It ought to reduce the
number of people who try to include kernel only stuff without knowing
that it is a nono most of the time.
It isn't all that hard to add the following lines to the Makefiles
for an application that needs the kernel includes:
KERNELDIR=/usr/src/linux
CFLAGS+=$(KERNELDIR)/include
And then standardise on /usr/src/linux as the directory where the kernel
includes for the current kernel reside on a distribution. Those who
compile multiple kernels on the same system should be savvy enough to
do "KERNELDIR=/usr/src/my-kernel/linux make" or modify the Makefile.
David Howells
> I notice just about everybody suggesting absolute paths.
>
> Try relative paths or environment variables instead. This has the
> advantage of working anywhere you damn well please.
Relative to what? Which environment variables? Who sets these variables?
David Howells
Miquel van Smoorenburg
H. Peter Anvin <h...@zytor.com> wrote:
>Followup to: <8m4uri$d9e$1...@enterprise.cistron.net>
>By author: miq...@cistron.nl (Miquel van Smoorenburg)
>In newsgroup: linux.dev.kernel
>>
>> >> Everything in /usr/include belongs to and depends on glibc, not
>> >> the currently running kernel.
>> >
>> >which talk to Linux-specific kernel interfaces, such as automount, you
>> >need both the glibc and the Linux kernel headers.
>>
>> probably best off by using a talktokernel.c file that is
>> compiled with -I/path/to/kernel/include while the rest of the
>> daemon doesn't know about kernel internals.
>>
>> That could and perhaps should be fixed, but I think that is
>> a different issue entirely.
>
>For most kernel interface daemons, that is not an option. You need to
>be able to translate (or just transfer information) between
>glibc-provided and kernel-provided data structures, so you need to be
>able to include all the datatypes.
Why? As I said you can use a glue layer. Note that you still
cannot mix /usr/include/net and /usr/src/linux/include/net anyway,
so clashes will always exist with the current system.
I agree it should probably be fixed.
>Let's get this straight: #include <linux/*> and #include <asm/*> are
>*expected* to be the kernel headers. This is a completely different
>issue from the fact that glibc headers shouldn't #include these
>headers like libc5 did.
But again as I said that is a different issue. This thread (with the
misleading Subject: header) is mostly about how to build modules
correctly.
There are 3 different issues here:
1. Consistent build environment for 3rd party modules
2. kernel-provided data structures for system daemons like autofs
3. kernel-provided data structures being used in glibc headers
I was merely talking about #1
Mike.
--
Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.
-
Miquel van Smoorenburg
Mike Castle <dal...@ix.netcom.com> wrote:
>On Mon, Jul 31, 2000 at 09:15:43PM +0000, Miquel van Smoorenburg wrote:
>> modules that use include/net ? The one in the kernel source is
>> very, very different from the one in glibc .. so you have to compile
>> with -I/path/to/kernel/include _anyway_
>
>Maybe just make it mandatory that every time you upgrade the kernel, you
>should rebuild the entire system.
Well for modules, yes, that is pretty much the case isn't it ?
H. Peter Anvin
By author: Mike Castle <dal...@ix.netcom.com>
In newsgroup: linux.dev.kernel
>
> On Mon, Jul 31, 2000 at 03:13:55PM -0700, H. Peter Anvin wrote:
> > which talk to Linux-specific kernel interfaces, such as automount, you
> > need both the glibc and the Linux kernel headers.
>
> we should be running /lib/modules/`uname -r`/sbin/automount.
>
No, it doesn't.
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
H. Peter Anvin
> cannot mix /usr/include/net and /usr/src/linux/include/net anyway,
> so clashes will always exist with the current system.
> I agree it should probably be fixed.
>
A GLUE LAYER IS FREQUENTLY NOT AN OPTION, because you have no data
types to carry around the semantic contents in. You really *DO* need
to mix both types.