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: