>From: Arthur Jerijian <t-arthje@microsoft.com>
>Date: Sun, 3 Sep 95 14:36:05 PDT
>Subject: Re: having System.map reflect the running kernel
>
>> 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.
This is what the NetBSD/FreeBSD/Mach boot loaders already do,
and it works rather well for loading large boot images.
A while ago I even created a little (~14K) patch to Linux
that allows you to boot a plain uncompressed, unstripped Linux kernel image
(i.e. the thing you get in /usr/src/linux/vmlinux, as opposed to
/usr/src/linux/arch/i386/boot/zImage) from the NetBSD and FreeBSD
32-bit boot loaders, as well as LILO and other Linux boot loaders.
It even supports ELF as well as a.out kernel images. However, it's
been a few months since I've updated it, so there's a good chance
it doesn't work right off in the newer kernels, and it was only an
incomplete prototype anyway.
(I wrote this for the MultiBoot project - an ongoing attempt at
creating a 32-bit OS image format/interface "standard" that allows
various boot loaders to load various 32-bit operating systems in any
combination from different sources such as filesystems, LILO-style
disk block lists, network, flash memory, etc. See
ftp://kahlua.cs.utah.edu/private/boot/README for more information.
The project is still active, but temporarily on the back burner
for lack of time on the part the people involved.)
>From: Snow Cat <snowcat@gd.cs.CSUFresno.EDU>
>Date: Mon, 4 Sep 1995 10:08:25 -0700 (PDT)
>Subject: Re: having System.map reflect the running kernel
>
>Why so complicated? :) Just go to protected mode, set ds,es,fs and gs to
>segments with 4GB limit and then go to real mode without reloading them
>with 64K segments. Then one can accesss all 4GB in memory (for example
>xor ax,ax; mov ds,ax; mov eax,[0x10000000H]) AND make 16 bit BIOS calls.
Sorry, tried it, it doesn't work. :-) The first time the BIOS saves,
changes, and restores those segment registers, you'll lose the high limits.
And from reading the Intel CPU manuals, doing this is clearly be a no-no
anyway, and could easily break on future processors.
Nevertheless, it's really not that difficult to do it right, as numerous
DOS extenders have demonstrated. I even wrote one myself - it's under the
GPL, and you're welcome to rip out the mode switching code and hack it
into Linux if you want. :-) Of course, it would require quite a bit
of testing and tweaking and working around obscure hardware bugs
before the Linux community as a whole could be moved to a 32-bit boot
system. But then, new unstable experiments are what 1.3.x is all about, right? :-)
(And the presence of the new mechanism wouldn't imply getting rid of the old one
immediately, by any means - the changeover could be as gradual as necessary.)
Bryan