Re: [ANNOUNCE] Gujin graphical bootloader 0.4

Etienne Lorrain (etienne_lorrain@yahoo.fr)
Mon, 13 Aug 2001 14:05:05 +0200 (CEST)


> This is indeed a good structure, but this wide interface is a pain to
> keep stable, and having bootloaders call it directly is a genuinely
> bad idea. It will lock us into an interface, or cause major breakage,
> when we have to do necessary revving of this interface.

Note that this interface is so stable that the structure did not change
for a long time. If someone wants to change it completely, he will
have to rewrite tools which are accessing this structure (rdev) and
also the bootloaders which are setting up fields into it already.
This will involve re-coding real-mode i8086 assembly, and there is less
and less people knowing how to do it.

> Instead, the proper time to deal with this is at kernel link time.
> The PC-BIOS stuff should go in, say arch/i386/pcbios, and you then can
> have other platforms (say, for example, arch/i386/linuxbios) which has
> its own setup code. You then link a kernel image which has the
> appropriate code for the platform you're running on, and you're set.

I can see your point about keeping functions which set up the structure
and function which uses it in a single kernel release.
In fact, all the functions setting this structure are in the same
file in Gujin, vmlinuz.[ch]. This file could one day go into the Linux
kernel, but we are no more speaking of compatibility.

My main problem is the order the things are done: First load compressed
files at defined addresses, then call a kernel function which callback the
BIOS, then uncompress files.

Once Gujin has started, I have a complete C environment so I can load
files, treat errors, display messages. I can do this either from cold
boot or from DOS (think of the first install of Linux on a system).

A good solution would be to have the kernel being two (or three) GZIP
files concatenated, the first would be the real-mode code to setup
the structure only, the second would be the protected-mode code of the
kernel (and the third the initrd). The first part would be a position
independant function getting some parameters (address/max size of the
structure to fill in) and returning information like microprocessor
minimum requirement, video mode supported (number of BPP, or text only),
address the kernel has been linked (to load a kernel at 16 Mb), ...

Then I would call this setup function before doing invalid things like
writing in the "DOS=HIGH" area. Note also that Gujin do not keep the
compressed kernel/initrd files, it reads a block and uncompress it
immediately because of the 64Kb limit on the data section.

This interface would still not handle a distribution where there is
few kernel files:
/boot/Linux-2.4.8-SMP
/boot/Linux-2.4.8-UP
/boot/Linux-2.4.8-386
/boot/Linux-2.4.8-Pentium
And the bootloader should just select automagically the right kernel.

I have to say that I simply do not have time to do such a thing,
because I have a lot of other problems in Gujin: it is already
a Linux-3.0 bootloader, not Linux-2.5 .
Moreover, going from a simple solution (loading the binary image of
an ELF file) to a complex one (as described) to solve problem which
may appear in the future is not my way of thinking: it is already
complex enought to do simple software.

Etienne.

___________________________________________________________
Do You Yahoo!? -- Vos albums photos en ligne,
Yahoo! Photos : http://fr.photos.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/