kernels, header files, modules and a read-only /usr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  (ok, it's my turn to ask dumb questions again.)

  following up on a previous post of mine, i'm still trying
to clarify the issues related to building and running a new
kernel, and header files.

  historically, of course, the kernsl source has always been
dumped under /usr/src/linux-2.x.yy or something to that effect.
and, from memory, it was always recommended to create the symlink
/usr/src/linux to point at the source directory for the currently
running kernel.

  why was this?  IIRC, it's because other builds needed access
to the kernel header files for the currently-running kernel so
they could be created compatible, is that about right?  and,
from tradition, those builds would look for /usr/src/linux to
get access to the header files.

  but there is now a glibc-kernheaders RPM for red hat, so is
there any need for that symlink any more?  i certainly don't
bother creating it any more since i moved up to the 2.5 kernel,
and i've never had any problems.

  but there's also the issue that, certainly, the header files
included in glibc-kernheaders, being part of a fixed RPM, are
not going to keep up with the possibly updated header files 
in the new kernel source tree.  there's no reason to expect
that a newer kernel source tree won't have, perhaps, updated
header files.  so it's reasonable to expect that there might
be differences between the header files in the glibc-kernheaders
RPM and those in the source tree for the current kernel.  can
anyone clarify that relationship?

  in addition, if there is no further need for the /usr/src/linux
symlink, this suggests that there's no need for the kernel source
tree to be under /usr/src (which was a silly place for it all the
time, since it prevented /usr from being mounted read-only).

  as long as kernel and RPM builds took place under /usr/src, it
kept /usr from really being available for RO mounting.  is there
anything to stop one from downloading and building a new kernel
elsewhere?  or perhaps making /usr/src a symlink to something
outside /usr, so /usr can finally be mounted read-only unless
you explicitly want to make some changes?

  in short, the questions:

1) what is the relationship between the header files in the
   glibc-kernheaders RPM and those in the (unrelated)
   kernel source tree?

2) is there any need for the historical /usr/src/linux
   symlink to the actual kernel source tree anymore?

3) if an application truly needs access to the header files
   for the current kernel, is it now official to get them
   via the symlink /lib/modules/2.5.xx/build?  (which,
   of course, makes the /usr/src/linux symlink redundant.)

4) is it necessary to build new kernels under /usr/src, or can
   the kernel source and build be located anywhere at this point?

5) can one just use a symlink to move /usr/src out of /usr once
   and for all?

6) is there a doc or URL that covers all this?

thanks.


--

Robert P. J. Day
Eno River Technologies
Unix, Linux and Open Source training
Waterloo, Ontario

www.enoriver.com




[Index of Archives]     [Fedora Users]     [Centos Users]     [Kernel Development]     [Red Hat Install]     [Red Hat Watch]     [Red Hat Development]     [Red Hat Phoebe Beta]     [Yosemite Forum]     [Fedora Discussion]     [Gimp]     [Stuff]     [Yosemite News]

  Powered by Linux