Re: having System.map reflect the running kernel

Werner Almesberger (almesber@lrc.epfl.ch)
Tue, 5 Sep 1995 12:45:28 +0200 (MET DST)


Hans Lermen <lermen@elserv.ffm.fgan.de> wrote:
> But I guess we should code the kernel version into it, something build
> from UTS_RELEASE, LINUX_COMPILE_BY, LINUX_COMPILE_HOST, e.t.c.

Don't forget the target architecture.

> We could have all these map files in a directory /boot/kernel-maps.

Hmm, this would rule out the possibility to put /boot on a plain MS-DOS
file system. (No symbolic links and restricted file names.) Some place
in /var might be better.

> If we, at init time, interprete /proc/version, we would be able to access
> the right System.map

This sounds reasonable. I see two problems resulting from the fact that
the (usually mnemonic) kernel name couldn't be easily translated to the
map name:

- if the kernel you're analyzing is not the kernel you're running,
you have to enter the version string manually (painful)
- if you're deleting an old kernel image, it's hard to find the
right map to remove

I think adding a plain text version string to the kernel image would be
the best approach to make such a translation easy again. (Including the
mnemonic name in the system map file name would require one to rename
the map when renaming/moving the kernel.)

LILO users could even have an automatic cleanup procedure, because
they already have a central registry for valid kernels (/etc/lilo.conf).

> [ Header proposal ]
> If we add the name of the system map, the loaders could get this string
> and pass it via command-line argument.

Yes, but if you move the system map, you have to modify that header too.
This is a lot less flexible than your previous proposal.

Besides, if you add a header like that, I'd suggest to store a full
command-line (-prefix/-trailer) there, so that other items can be
added in the future without changing the header format.

If Linus doesn't like the header idea, one could also use a trailer
instead. (To construct: add one stop character (if it's printable,
one could even use echo as the construction tool), then the string.
To read: seek to the end, then read backwards until the stop character
is found.)

By the way, did anybody realize that gunzip puts 105 bytes of version
strings into uncompressed part of our kernels ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, DI-LRC,EPFL,CH   werner.almesberger@lrc.di.epfl.ch /
/_IN_R_311__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/