Re: [ANNOUNCE] Gujin graphical bootloader 0.4

[Eric W. Biederman]

"H. Peter Anvin" <[e-mail]> writes:

> Followup to:  <[e-mail]>
> By author:    Etienne Lorrain <[e-mail]>
> In newsgroup: linux.dev.kernel
> > 
> >  - Loads Linux kernel images (zImage and bZimage) without the help
> >    of LILO, and short-circuit all real-mode code in the kernel to
> >    start at the first protected mode instruction of the kernel.
> > 
> 
> This is a very bad idea.  The kernel entry point is in real mode for a
> reason: it means that the kernel doesn't have to rely on the boot
> loader to provide the services it needs from real mode before
> entering protected mode once and for all.  The interface to the real
> mode entry point is narrow and stable, the protected mode entrypoint
> is a kernel internal and doesn't have an interface that is guaranteed
> to be stable -- again, for good reason.

There are good reasons to use the kernel 32 bit entry point.  In
particular I routinely run linux on systems with exactly 10 16bit
instructions.   On one of them I don't even have normal memory between
640KB and 1MB. The only real parameter the kernel needs from the BIOS
is memory size, and I could probably steel code from memtest86 so it
wouldn't even need that.  

However I do understand the instabilities, and the deficiets of the
current 32bit entry point, and why having a standard 16bit entry point
is a good thing.  Which is why in 2.5 (if it ever starts) I intend to
do the work required so we can have a standard cross platform native
mode entry point to the kernel.  

To keep linux portable we should never assume that on a given platform
there is a specific kind of BIOS.  Alpha-linux at least is nasty
because of this.  x86 linux is very nice because all you need to do on
platforms that don't do support the classic BIOS interface is to drop
the 16bit header.  That is definentily a structure worth keeping.

Currently I have a stable easy to use structure that isn't even linux
specific with just a few more details on how to encode parameters to
work out.  The structure is the ELF format for static executables,
with a specific implementation of how parameters will be passed to it
from the bootloader, before the bootloader goes away.  In particular
how to specify things like onboard ISA devices so we don't even have
to assume what is or is not present on a motherboard for those devices
that don't support probing and there is a firmware interface for
finding them.  The interesting case there is not so much how to encode
the device but instead on how to represent the location of devices,
and the connections between devices.   

Being able to describe how an interrupt goes from a pci slot to an irq
router to a legacy interrupt controller to a local apic and to the
cpu, and simultanesly goes from the pci slot to an ioapic to a local
apic to the cpu.   And saying that pci slot is behind a PCIX<->pci
bridge.  Is an interesting question.  Especially in data structures
that have very few special cases.  We are close in the kernel with
struct resource, and struct pci_device but we haven't gone all of the
way yet. 

So no I don't think it is right to blast someone for using the 32bit
entry point, while at the same time I do agree that right now it is a
very questionable things to do.

Eric