[email protected] (Jesse Pollard) wrote on 27.07.00 in <[email protected]>:
> 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?
I think this is silly.
There are two versions of header files people tend to be interested in:
a. The ones corresponding to the libc version their linker will link
against. This will be good for 99% of the situations.
b. A special version for some kernel-version-dependant executable. Exact
version depends on what they plan to do with that executable - could be
most advanced kernel version available, least advanced version available,
a specific version whose significance depends on the configuration of a
different machine, whatever.
There is no reason to assume that the currently running kernel version is
any more relevant than any of the other arguments for b.
> This way the kernel that is active would be selecting the correct includes.
Correct for what?
MfG Kai
On 31 Jul 2000, Kai Henningsen wrote:
> [email protected] (Jesse Pollard) wrote on 27.07.00 in <[email protected]>:
>
> > 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?
>
I must be able to build kernel modules for a kernel version that I
am not yet running. This is not related in any way to what I get from
`uname -r`. Further, I may be building the kernel for an Alpha on
an Intel machine, using a cross-compiler.
The de-facto standard has been that /usr/src/linux is a sym-link to
the kernel version you wish to build. Why is this expected to be
changed?
Since this is a symbolic link, it can cross device boundaries. This
makes it very versatile.
/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.
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.
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.
On Mon, 31 Jul 2000, Richard B. Johnson wrote:
> On 31 Jul 2000, Kai Henningsen wrote:
>
> > [email protected] (Jesse Pollard) wrote on 27.07.00 in <[email protected]>:
> >
> > > 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