link /lib/modules/<vers.>/build

Richard Lightman richard at reika.demon.co.uk
Tue Jul 3 03:15:07 PDT 2001


Misquoted from David A. Bandel on 2001/07/ 2 at 08:17 +0000:
> Richard Lightman wrote:
> > 
> > Misquoted from Gerard Beekmans on 2001/07/ 1 at 11:19 +0000:
> > >
> > > The problem though, the kernel docs and config file. There's no official
> > > place to store those. I could think of /usr/share/doc/linux (or
> > > /usr/share/doc/kernel) for the Documentation/* stuff, but how about the
> > > .config file? /usr/share/kernel-config perhaps?
> > >
> > How about:
> > /lib/modules/$(uname -r)/config
> > 
> > And while you are at it:
> > /lib/modules/$(uname -r)/bzImage
> > /lib/modules/$(uname -r)/System.map
> 
> no -- the above two need to be in /boot.  Doing otherwise breaks
> tradition (and may break LSB/LHS compliance).  You can do /boot/$(uname
> -r)/ if you really want, though I see little need for it.
> 
If you are upgrading the kernel, and keeping the old one as
a fall back, how is klogd going to find the right symbols?
I have seen /boot/System.map as a symlink to the correct
file, but FHS says /boot can be mounted read-only, so
you cannot be sure that you can correct the symlink.

FHS says nothing about 'System.map', but the standard
behaviour of klogd is something you really want to override.

/boot makes some sense for people using lilo, they need
somewhere to keep their sector map files. It is a bit
pointless for grub, which does not use sector map files
for the kernels. If you have more than one root partion,
which is common among LFS'ers, grub is better off on a
partition that you do not wipe once a month, like say
/home, or a partition full of source tarballs.

I am happy to take the best ideas from FHS, and to do
something sensible instead where the standard has
accepted "common practice" instead doing something sensible.

Richard



-- 
Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the lfs-dev mailing list