Re: having System.map reflect the running kernel

Arthur Jerijian (t-arthje@microsoft.com)
Sun, 3 Sep 95 14:36:05 PDT


> From: Werner Almesberger <almesber@lrc.epfl.ch>
> Date: Sat, 2 Sep 1995 11:05:03 +0200 (MET DST)
> Subject: Re: having System.map reflect the running kernel

[ deleted ]

> - 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.

I have yet another idea. Why not make the 32-bit extender a separate
entity outside of the kernel? That way, when the system boots, the
extender can make all the memory available to load the uncompressed
kernel. Of course, some 16-bit BIOS calls will have to be made by the
extender for this purpose. Please correct me if I'm wrong, since I'm
not a hardware programmer.

> 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

--Arthur Jerijian t-arthje@microsoft.com until 15 Sep 1995

My opinions do not necessarily reflect those of any of my past or
present employers. And yes, this post is freely redistributable by
ANY third party. (C) 1995 Arthur D. Jerijian