[PATCH 1/3] Gujin linux.kgz boot format
Etienne Lorrain
This is following that set of patch:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112557274910448&w=4
to get a simpler structure of the vmlinux boot file, named like:
/boot/linux-2.6.14.kgz
This linux-*.kgz format is the "native" format of the Gujin
bootloader which can be found here:
http://gujin.org
The main change of this set of patch is the rewrite of nearly all
the ia16/ia32 assembler of Linux into a C file named "realmode.c",
and its include "realmode.h". The mapping of the 4 Kbytes memory
page exchanged in between real mode and protected mode is exactly
the same, but is described in a C structure - a lot cleaner.
Another big change is that the GZIP compressed file produced during
Linux compilation now contains a comment describing some important
information: which processor this kernel has been compiled for (so
no invalid instruction crash when running a Athlon compiled kernel
on a Pentium - but a nice error message from the bootloader), which
video mode the kernel support (VGA text or VESA, and which VESA)...
If you apply this set of patch, you still can use the old method
to boot a kernel with LILO, Loadlin, Grub or SYSLINUX, and this
patch will not modify any assembler instruction executed on this
boot path when you use "make bzImage" or the like.
To produce the new format you just have to apply at least the
first two patch and type "make /boot/linux-gujin.kgz ROOT=auto",
or apply the 3rd patch to get root autodetection (based on the
partition/directory of the linux*.kgz file loaded) and type
"make /boot/linux-gujin.kgz". (also see "make help")
This set has few changes: applies on all distributions (end-of-line
at end-of-file problem on Fedora3), updated to apply on 2.6.13-rc3 -
or 2.6.13.rc2-mm2 with few offsets, compiles also without warnings
on GCC-2.95.3 and GCC-4.0.*, links without problem (no more
memcpy()/memset() called).
It perfectly works for me, and even after reading those tens of times
I no more find anything to change or improve.
Can someone propose a way forward, either in the direction of
linux-2.6.14/15 or in the -mm tree, and/or propose improvement or
point me to my bug(s) ?
Attached first patch just add two standalone executable, one
to manage GZIP comments, the other to display a text line of the
parameters used to compile the kernel.
Signed-off-by: Etienne Lorrain <etienne...@gujin.org>
Etienne.
Etienne Lorrain
and how to compile them and insert then at the end of the ELF file.
The resulting linux.kgz can be used with Gujin but the "root="
parameter has to be given manually.
Etienne Lorrain
of the patches during attachement.
To rebuild them, just add a newline at end of each file:
$ wget
'http://marc.theaimsgroup.com/?l=linux-kernel&m=112859209607340&q=p3' -O
patch2614rc3-1
$ wget
'http://marc.theaimsgroup.com/?l=linux-kernel&m=112859247823724&q=p3' -O
patch2614rc3-2
$ wget
'http://marc.theaimsgroup.com/?l=linux-kernel&m=112859247807836&q=p3' -O
patch2614rc3-3
$ echo >> patch2614rc3-1
$ echo >> patch2614rc3-2
$ echo >> patch2614rc3-3
$ cd linux-2.6.14-rc3
$ patch -p1 -i ../patch2614rc3-1
$ patch -p1 -i ../patch2614rc3-2
$ patch -p1 -i ../patch2614rc3-3
Etienne.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
> It perfectly works for me, and even after reading those tens of times
> I no more find anything to change or improve.
> Can someone propose a way forward, either in the direction of
> linux-2.6.14/15 or in the -mm tree, and/or propose improvement or
> point me to my bug(s) ?
And advantages are? Having to maintain both C and assembly version
does not seem like improvement to me.
> +#define STR static const char
Ouch.
Pavel
+const unsigned maskvesa = 0
> +#ifndef CONFIG_FB_VESA
> + | (1 << 0) /* Cannot boot in MASKVESA_1BPP */
> + | (1 << 1) /* Cannot boot in MASKVESA_2BPP */
> + | (1 << 3) /* Cannot boot in MASKVESA_4BPP */
> + | (1 << 7) /* Cannot boot in MASKVESA_8BPP */
> + | (1 << 14) /* Cannot boot in MASKVESA_15BPP */
> + | (1 << 15) /* Cannot boot in MASKVESA_16BPP */
> + | (1 << 23) /* Cannot boot in MASKVESA_24BPP */
> + | (1 << 31) /* Cannot boot in MASKVESA_32BPP */
> +#endif
> +#if defined (CONFIG_VGA_CONSOLE) || defined (CONFIG_MDA_CONSOLE)
> + | (1 << 16) /* able to boot in text mode */
> +#endif
> + // | (1 << 17) /* not able to boot in VESA1 mode */
> +#ifdef CONFIG_FB_VESA
> + | (1 << 18) /* able to boot in VESA2 linear mode */
> +#endif
> + // | (1 << 19) /* force VESA1 if in VESA2 */
> + | (1 << 20) /* Cannot handle VGA graphic modes */
> + ;
--
if you have sharp zaurus hardware you don't need... you know my address
Etienne Lorrain
>> It perfectly works for me, and even after reading those tens of times
>> I no more find anything to change or improve.
>> Can someone propose a way forward, either in the direction of
>> linux-2.6.14/15 or in the -mm tree, and/or propose improvement or
>> point me to my bug(s) ?
>
> And advantages are? Having to maintain both C and assembly version
> does not seem like improvement to me.
The problem is that you call the assembly version "maintained".
When I started hacking that part, in 1998, I tried to rewrite it
cleanly and fix obvious bugs - but assembler is not the right tool
for this job and touching those assembler files would break some
configuration - even if some other configuration would work better.
I am not alone to not want to touch those assembler files: If you
have a look at Linux/arch/x86_64/boot/video.S you will see that
on an X86_64 architecture, people are doing I/O port and PCI
peek/poke all over the place to detect video cards which have
only been available on ISA bus, two bus generation ago!
I seriously doubt you can even imagine an AMD 64 bits with an ISA
trident 8900 video card inside, even for fun: you cannot plug it in.
The problem of assembler is that when it has been put in, you cannot
remove anything because at the time you want to remove old stuff,
you no more understand the implications. You can not, like in C,
stop calling a function and hope everything will be right. With my
code, when you will want to get rid of the APM stuff, you just
remove the function call vmlinuz_APM() and recompile.
I am, with this set of patch, proposing a new way to boot. This
way enable you to boot unlimited size kernel ("make allyesconfig"
produces a bootable linux.kgz kernel) and the BIOS information
collection is done in C while in real mode. This real mode function
can be a lot bigger than it is currently, so that you can temporarily
call some printf() equivalent while collecting data - instead of
trying to get a clue of what has happen *after* the crash.
There is no extended time spent in protected mode (unlike Grub)
before collecting BIOS information, so that the BIOS environment
has not been broken (for instance older BIOS APM power saving system
would be active at startup on some PC, setting timer interrupt to
slowly reduce power consumption in real mode. Grub switching to
protected mode stop serving those interrupts, and may not work on
this PC, or the BIOS information may be invalid).
>> +#define STR static const char
>
> Ouch.
Well, you want to comment on the only file which is a standalone
application and not released under GPL but BSD license, because it
may be usefull elsewhere.
I have written:
#define STR static const char
then 50 strings, then
#undef STR
The main advantage is that it saves screen space, when you want to
group all the messages together because this standalone utility may
be translated to other languages, unlike the kernel itself.
The way to support other languages in C can be complex, and all
those string can also be wchar_t, or an array of array of chars,
and the "static" keyword may or may not be a good idea.
The fact that it is released on a BSD license (if a collection
of GZIP utilities is ever built) also changes the indentation
rules if that matter.
I am not sure we want to talk a lot about this file, it is just
a simple executable to edit a string at a fixed position inside
an otherwise binary file (as GZIP specifications), it can be
written in a lot of other languages, or with shell commands
like "cut" and file concatenation - it is just cleaner this way.
> Pavel
> +const unsigned maskvesa = 0
>
>> +#ifndef CONFIG_FB_VESA
>> + | (1 << 0) /* Cannot boot in MASKVESA_1BPP */
>> + | (1 << 1) /* Cannot boot in MASKVESA_2BPP */
>> + | (1 << 3) /* Cannot boot in MASKVESA_4BPP */
>> + | (1 << 7) /* Cannot boot in MASKVESA_8BPP */
>> + | (1 << 14) /* Cannot boot in MASKVESA_15BPP */
>> + | (1 << 15) /* Cannot boot in MASKVESA_16BPP */
>> + | (1 << 23) /* Cannot boot in MASKVESA_24BPP */
>> + | (1 << 31) /* Cannot boot in MASKVESA_32BPP */
>> +#endif
>> +#if defined (CONFIG_VGA_CONSOLE) || defined (CONFIG_MDA_CONSOLE)
>> + | (1 << 16) /* able to boot in text mode */
>> +#endif
>> + // | (1 << 17) /* not able to boot in VESA1 mode */
>> +#ifdef CONFIG_FB_VESA
>> + | (1 << 18) /* able to boot in VESA2 linear mode */
>> +#endif
>> + // | (1 << 19) /* force VESA1 if in VESA2 */
>> + | (1 << 20) /* Cannot handle VGA graphic modes */
>> + ;
No comment here. Well I know the use of ifdef's is deprecated, but
there is simply no other way here - and lets face it: recompiling
a 10 lines C function (with the host compiler and not the target one
when cross compiling) at each kernel configuration change is not that
long.
Note that if you try to start with LILO a kernel in VESA graphic
mode and the kernel is not compiled with CONFIG_FB_VESA, well, no
error message is displayed because the kernel do not know how
to display stuff... With Gujin you cannot start this kernel and
you get a clear error message.
You can also try to start a kernel in 320x200 4 colors modes...
--
> if you have sharp zaurus hardware you don't need... you know my address
Sorry I do not... fun but not enough storage space.
Cheers,
Etienne.
Pavel Machek
> >> It perfectly works for me, and even after reading those tens of times
> >> I no more find anything to change or improve.
> >> Can someone propose a way forward, either in the direction of
> >> linux-2.6.14/15 or in the -mm tree, and/or propose improvement or
> >> point me to my bug(s) ?
> >
> > And advantages are? Having to maintain both C and assembly version
> > does not seem like improvement to me.
>
> The problem is that you call the assembly version "maintained".
> When I started hacking that part, in 1998, I tried to rewrite it
It seems to work okay here. Now, rewriting current boot system into C
may be good goal...
> I am not alone to not want to touch those assembler files: If you
> have a look at Linux/arch/x86_64/boot/video.S you will see that
> on an X86_64 architecture, people are doing I/O port and PCI
> peek/poke all over the place to detect video cards which have
> only been available on ISA bus, two bus generation ago!
> I seriously doubt you can even imagine an AMD 64 bits with an ISA
> trident 8900 video card inside, even for fun: you cannot plug it
> in.
Feel free to fix that. [I think I could get PCI-to-ISA bridge and plug
it into my x86-64 box...]
> >> +#define STR static const char
> >
> > Ouch.
>
> Well, you want to comment on the only file which is a standalone
> application and not released under GPL but BSD license, because it
> may be usefull elsewhere.
Well, if you want to distribute the file with kernel, it should
folllow kernel coding style. If not, sorry for the noise.
> The fact that it is released on a BSD license (if a collection
> of GZIP utilities is ever built) also changes the indentation
> rules if that matter.
License does not say anything about coding style.
// comments are deprecated, too, and you probably should use symbolic
constant, no?
> > if you have sharp zaurus hardware you don't need... you know my address
>
> Sorry I do not... fun but not enough storage space.
Takes CF cards just fun. You can get 1GB CF cards these days, and
microdrives are even bigger.
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address
Etienne Lorrain
> may be good goal...
At least that is a way which does not involve modifying assembler
files. Slowly everybody switches to the C version which continue
to evolve (i.e. removing old BIOS calls), then the tree under
arch/i386/boot is removed and we can begin to rearrange the mapping
of "struct linux_param".
>> I seriously doubt you can even imagine an AMD 64 bits with an ISA
>> trident 8900 video card inside, even for fun: you cannot plug it
>> in.
>
> Feel free to fix that. [I think I could get PCI-to-ISA bridge and plug
> it into my x86-64 box...]
Well, I can help to plug it in, but it involves a set of tool not
usually used in computer software, that is hammer and axes :-)
For the software support of VESA 1 bank switching to display graphic
modes in 64 Kbytes memory window, well, Gujin support it but not Linux.
For my future investment in a x86-64, well I will one day, it is on
my TODO list. I wonder about PCI-E -> ISA converter, they should be
faster than PCI -> ISA, no?...
>> Well, you want to comment on the only file which is a standalone
>> application and not released under GPL but BSD license, because it
>> may be usefull elsewhere.
>
> Well, if you want to distribute the file with kernel, it should
> folllow kernel coding style. If not, sorry for the noise.
I hope I can still put a BSD license "helper" in kernel tree, it
is BSD because GZIP is itself BSD licensed - and its indentation
looks like GZIP source.
For the "//" comment I have to check those patches; I am used to put
them when the user may think of changing it for configuration.
I do not want to use symbolic constant, as in:
static const unsigned MASKVESA_1BPP = 1 << 0;
because the assembler generated is bad (a real area of memory is
reserved - it is constant in C but may be modified in assembler).
I do not put my constant as enum because I am still not a real
C++ software writer (don't tell my boss!).
I could do:
#define MASKVESA_1BPP (1 << 0)
as in Gujin vmlinuz.h, but because it is used once and only once,
I did put MASKVESA_1BPP as comment (use one source line instead
of two). I can change it, I have enough spare "linefeed" -:)
My bigger problem was for the CPUID detection, I did not know if
I should use Gujin library.h structure:
struct cpuid_flags_str {
unsigned fpu : 1;
unsigned vme : 1;
unsigned de : 1;
unsigned pse : 1;
unsigned tsc : 1;
unsigned msr : 1;
unsigned pae : 1;
unsigned mce : 1;
unsigned cx8 : 1;
unsigned apic : 1;
unsigned unused3 : 1;
unsigned sep : 1;
unsigned mtrr : 1;
unsigned pge : 1;
unsigned mca : 1;
unsigned cmov : 1;
unsigned pat : 1;
unsigned pse36 : 1;
unsigned psn : 1;
unsigned clfl : 1;
unsigned unused2 : 1;
unsigned dtes : 1;
unsigned acpi : 1;
unsigned mmx : 1;
unsigned fxsr : 1;
unsigned sse : 1;
unsigned sse2 : 1;
unsigned ss : 1;
unsigned htt : 1;
unsigned tm : 1;
unsigned ia64 : 1;
unsigned unused1 : 1;
unsigned mapping_to_define;
} __attribute__ ((packed));
and:
struct cpuid_amd_flags_str {
unsigned fpu : 1;
unsigned vme : 1;
unsigned de : 1;
unsigned pse : 1;
unsigned tsc : 1;
unsigned msr : 1;
unsigned pae : 1;
unsigned mce : 1;
unsigned cx8 : 1;
unsigned apic : 1;
unsigned unused3 : 1;
unsigned sep : 1;
unsigned mtrr : 1;
unsigned pge : 1;
unsigned mca : 1;
unsigned cmov : 1;
unsigned pat : 1; /* or FCMOV */
unsigned pse36 : 1;
unsigned unused2 : 4;
unsigned mmxplus : 1;
unsigned mmx : 1;
unsigned fxsr : 1; /* or emmx, Cyrix */
unsigned unused1 : 4;
unsigned lm : 1;
unsigned E3Dnow : 1; /* Extended 3DNow!+ */
unsigned S3Dnow : 1; /* Standard 3DNow! */
} __attribute__ ((packed));
and because of the complexity decided to build the constant
manually, which led to manual building of the video constant.
Somebody else would like some other modifications?
Cheers,
Etienne.
Pavel Machek
> > It seems to work okay here. Now, rewriting current boot system into C
> > may be good goal...
>
> At least that is a way which does not involve modifying assembler
> files. Slowly everybody switches to the C version which continue
> to evolve (i.e. removing old BIOS calls), then the tree under
> arch/i386/boot is removed and we can begin to rearrange the mapping
> of "struct linux_param".
Will your C version work with lilo and grub?
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
Etienne Lorrain
>> > may be good goal...
>>
>> At least that is a way which does not involve modifying assembler
>> files. Slowly everybody switches to the C version which continue
>> to evolve (i.e. removing old BIOS calls), then the tree under
>> arch/i386/boot is removed and we can begin to rearrange the mapping
>> of "struct linux_param".
>
> Will your C version work with lilo and grub?
Tricky question. In short no, it cannot.
It is in fact theoretically possible to boot the same way for LILO,
Grub and SYSLINUX to still work, and then call this linux_set_params()
function but involves a lot of assembler programming and linker setup.
I have done this exact work once with Gujin, but then I was in full
control of the bootloader, in a setup which was already in C, has the
stack setup, where I can free the first 4 Kbytes of data (located at
address 0) for use by this kernel function. It was far to be simple.
One of the problem I can see is that you currently have two link
being done by the linker, one in real mode and one in protected mode.
You cannot have cross references in between those two links, and for
instance with Gujin, you are filling the content of the LnxParam
pointer, which is transparently copied at its right position before
jumping to the Linux kernel code. You will need a seriously more
complex linker file to forbid cross references, and duplicate Gujin
treatment about memory setup (in this case that may involve HIMEM/EMM
primitive calling if starting under DOS).
Note that if this kernel function returns an error, Gujin will
display an error message and you can select another kernel to boot,
but you cannot return to LILO or Grub with an error...
Modifying the bootloader may be possible, but lately I had another
look at LILO source and I do not want to touch it. If you run Grub,
you loose the "BIOS information gathering before switching to
protected mode" advantage, BIOS environment may still be broken.
SYSLINUX is probably at lot more accessible, and Gujin still do
not support network booting (It can be added, but my TODO list is
long), but you will want to call a function which is curently at
the end of a still compressed image.
Sorry I cannot be compatible with them, please note that
Gujin is also GPL.
Etienne.
Pavel Machek
> >> > may be good goal...
> >>
> >> At least that is a way which does not involve modifying assembler
> >> files. Slowly everybody switches to the C version which continue
> >> to evolve (i.e. removing old BIOS calls), then the tree under
> >> arch/i386/boot is removed and we can begin to rearrange the mapping
> >> of "struct linux_param".
> >
> > Will your C version work with lilo and grub?
>
> Tricky question. In short no, it cannot.
I do not see a point, then. We have bad assembly bootup code. Adding
good C bootup code, that is incompatible with lilo/grub does nothing
to clean the mess up.
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address
Kalin KOZHUHAROV
>>>>It seems to work okay here. Now, rewriting current boot system into C
>>>>may be good goal...
>>>
>>> At least that is a way which does not involve modifying assembler
>>> files. Slowly everybody switches to the C version which continue
>>> to evolve (i.e. removing old BIOS calls), then the tree under
>>> arch/i386/boot is removed and we can begin to rearrange the mapping
>>> of "struct linux_param".
>>
>>Will your C version work with lilo and grub?
>
>
> Tricky question. In short no, it cannot.
[snip a long explaination of why this is practically impossible]
> Sorry I cannot be compatible with them, please note that
> Gujin is also GPL.
So you are saying: "Dump GRUB and lilo, use Gujin!" ??
I don't think anybody will agree with that even if it is a better way in some way.
Until some level of compatibility is guaranteed with the currently de facto loaders, at least I
cannot support this idea in any way. Discussing that with GRUB and lilo devs, might be an idea, but
who knows.
Kalin.
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
Etienne Lorrain
> So you are saying: "Dump GRUB and lilo, use Gujin!" ??
>
> I don't think anybody will agree with that even if it is a better
> way in some way.
> Until some level of compatibility is guaranteed with the currently
> de facto loaders, at least I cannot support this idea in any way.
> Discussing that with GRUB and lilo devs, might be an idea, but
> who knows.
It is even worse than that, I not only said to change the
bootloader but also to remove one of the two links produced
during a standard "make bzImage", the one which handle the
real mode ia32 code, in Linux/arch/i386/boot/*.
Sometimes, to simplify, you need to remove things. As I said,
a Linux kernel "linux.kgz" is just a compressed binary image of
an ELF file - it no more deals with real mode, its first
instruction is in protected mode (no virtual memory, just flat
one, and interrupts disabled). It still contains the processor
it is compiled for in the GZIP comment part, in text mode.
That has advantages like that you use a clean real mode
environment to get all the BIOS information you want, the
first kernel assembler instruction can be located anywhere in
memory (even at an address currently used by BIOS/DOS because
the relocation is very late), and there is no more any limit
to the kernel size.
So, at the bootloader time, you can start a FreeDOS environment
with DOS USB drivers and load your kernel at any address you want,
or decide that you do not want to touch the BIOS environment
and boot from a simulated floppy on a ATAPI IDE CDROM.
If your kernel no more boots (got a HD with SMART failure lately),
you can get an error while loading the kernel and just can boot
a CDROM with a IDE disk RMA generator.
When network support will be included in Gujin, because the
processor is still in real mode, it will be able to use the
network BIOS with its IRQ in a transparent way.
Note that there is no more any development for LILO or the real
mode part of the kernel, probably people no more want to deal with
assembler software. I can't blame them, I stopped too to use
assembler in Gujin. I can't talk to the development teams of LILO
or the real mode part of the kernel...
Anyway, it is technically not possible to rely on the old real
mode interface because things are not done at the right time,
complete backward compatibility is kept because you just describe
what you want at the "make" time, by typing "make bzImage" or
"make /boot/linux-2.13.kgz".
I can't force anybody to switch to Gujin; I am just proposing a
way to start Linux which is a lot simpler, involves a lot less
assembler code so is a lot easier to maintain, which is working
right now, which is quite easy to debug (with the DBG*.exe files).
You can boot your PC with your USB FLASH disk, your CD/DVD-ROM
or a simple disk / partition / floppy right now, there isn't
any configuration file because everything is autodetected - at
least anything which cannot be selected by the graphic/mouse
interface.
http://gujin.org
Etienne.
Denis Vlasenko
> Hello,
>
> This is following that set of patch:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=112557274910448&w=4
> to get a simpler structure of the vmlinux boot file, named like:
> /boot/linux-2.6.14.kgz
>
> This linux-*.kgz format is the "native" format of the Gujin
> bootloader which can be found here:
> http://gujin.org
/me looking at the site
Wow. Isn't this overdesigned by wide margin?
> The main change of this set of patch is the rewrite of nearly all
> the ia16/ia32 assembler of Linux into a C file named "realmode.c",
> and its include "realmode.h". The mapping of the 4 Kbytes memory
> page exchanged in between real mode and protected mode is exactly
> the same, but is described in a C structure - a lot cleaner.
> Another big change is that the GZIP compressed file produced during
> Linux compilation now contains a comment describing some important
> information: which processor this kernel has been compiled for (so
> no invalid instruction crash when running a Athlon compiled kernel
> on a Pentium - but a nice error message from the bootloader), which
> video mode the kernel support (VGA text or VESA, and which VESA)...
>
> If you apply this set of patch, you still can use the old method
> to boot a kernel with LILO, Loadlin, Grub or SYSLINUX, and this
> patch will not modify any assembler instruction executed on this
> boot path when you use "make bzImage" or the like.
> To produce the new format you just have to apply at least the
> first two patch and type "make /boot/linux-gujin.kgz ROOT=auto",
> or apply the 3rd patch to get root autodetection (based on the
> partition/directory of the linux*.kgz file loaded) and type
> "make /boot/linux-gujin.kgz". (also see "make help")
Apart from shaving a few kb's from kernel image (which are discarded
anyway after boot, IIRC), what advantages does this bring?
Do they outweigh effort needed to maintain it?
--
vda
Etienne Lorrain
>> This linux-*.kgz format is the "native" format of the Gujin
>> bootloader which can be found here:
>> http://gujin.org
>
> /me looking at the site
> Wow. Isn't this overdesigned by wide margin?
Well, you will see Gujin with its video/mouse interface on the WEB,
because there is no point in just showing the tiny interface which
does not even detect which video mode (or serial interface) is
available. For that just imagine two line of text, the first being
the copyright, the second a set of point indicating the progress
being done loading from BIOS or from DOS.
Now if you want to tell me that it is a lot easier to write code
using GCC compared to an assembler, well I quite agree. The source
code size is approx the same as Grub, with a lot less files.
It is also a lot simpler to use the BIOS than to rewrite everything
to be able to switch to protected mode.
> Apart from shaving a few kb's from kernel image (which are discarded
> anyway after boot, IIRC), what advantages does this bring?
> Do they outweigh effort needed to maintain it?
Don't you think autodetection of the ways to boot a PC is a nice
feature, so that you just have _one_ rescue CDROM/floppy/pen drive
from now on? Also you just test a new Linux distribution without
changing your current bootloader configuration? At least, you do
not end up having 3 or 4 Grub and two LILO configured in 6 different
root filesystems, some of them on removeable HD...
Moreover, there is no need to provide boot floppies to install
distributions on PC which cannot boot CDROMs, just give a way
to make a Gujin floppy. It will load big kernel directly from
the CDROM ISO9660 filesystem, in /boot directory.
Etienne.