- LILO can already determine the path of the current kernel:
/sbin/lilo -I `tr '\0' '\012' </proc/1/environ |
sed '/BOOT_IMAGE=/s///p;d'`
(Inside init or the rc scripts, it's trivial.)
- as far as I know, LOADLIN doesn't do anything like this, but it
could for instance try to determine the path of the kernel image
and pass it as a command-line argument
- more exotic approaches (kernel-only boot floppy, network boot,
etc.) could be handled on a local basis. Also, we wouldn't need a
solution for all cases, e.g. it'd be rather pointless if a
distribution boot disk knew on which CD-ROM or FTP site to look
for the symbols ...
- if symbols are stored in a separate file, that file name (or a
link to it) should probably follow some conventions, e.g.
<path_to_kernel>.map
- unstripped kernels are another possibility with the following
drawbacks: they probably shouldn't be compressed either (objdump
and such want to lseek, so you couldn't just pipe the kernel
through gunzip), which slows down the load process and it also
makes them too big to load below 640kB. Since huge kernels will
grow beyond that limit anyway the sooner or the later, boot
loaders will have to be able to load beyond 1 MB, so the use of
unstripped kernels would only change the schedule.
IMHO, the current solution (kernel and map are two distinct files)
is a good solution, but it would be desirable to have slightly more
uniform names for the symbol files, e.g. $(INSTALL_PATH)/vmlinuz.map
and $(INSTALL_PATH)/vmlinuz.old.map
- 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_____________________/