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

boot-time kernel selection and /System.map mismatch



All the talk recently about selecting alternative kernels at
boot time reminded me of something I had noted earlier and not
pursued.

lsof(1), from the package of the same name, and possibly other
programs as well, use the /System.map file to figure out where
to peek at info in /dev/kmem.  This doesn't work if the /System.map
file doesn't match the running kernel.

I'm wondering if it would it be worthwhile to try to address this.
Two alternative approaches occur to me:

1.  Modify all the programs which use /System.map to search
    multiple .map files looking for one which matches the
    current kernel.

2.  During system init, try to find a .map file matching
    the booted kernel and symlink /System.map to it.

Alternative (2) sounds better to me.  However, both alternatives rely
on there being .map files available - probably in some designated
directory - for all those alternative kernels.  That implies the use
of a tool to install and remove those alternative kernels, so that
the .map files get installed and removed properly along with them.
(or if not a tool, it implies some manual procedures being followed
when installing and removing those alternative kernels)

I'm under the impression that we don't have a good track record
on debian-user-kernel-hackers (1) becoming aware of debian-specific
procedures for building and installing kernels, or (2) following
those debian-specific procedures if they are aware of them.

Is it worthwhile exploring this and trying to find a workable
approach to making programs such as lsof(1) workable with
boot-time selection of alternative kernels?  If so, we need
consensus on an approach.



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: