Re: linux-kernel-digest V1 #167

Bryan Ford (
Thu, 07 Sep 95 10:15:55 MDT

I suspect I missed an earlier part of this discussion,
so please excuse me if I say something that's already been said... :-)

>From: Arthur Jerijian <>
>Date: Sun, 3 Sep 95 14:36:05 PDT
>Subject: Re: having reflect the running kernel
>> From: Werner Almesberger <>
>> Date: Sat, 2 Sep 1995 11:05:03 +0200 (MET DST)
>> Subject: Re: having 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 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 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.)