Re: [gentoo-amd64] Re: Emerging package as both 64 and 32 bit

[Etaoin Shrdlu <shrdlu@unlimitedmail.org>]

On Tuesday 19 December 2006 16:01, Duncan wrote:

> Now, part of what I don't quite understand is how that 
> all fits together and whether the "microcore" is a dependency or
> actually compiled as part of the LILO compile and install process, or
> whether it's similar to the binary blob at the core of the NVidia
> video drivers (which I won't run as that blob isn't free software) and
> the LILO compile process simply builds a wrapper around that core. 

I'm not sure about the "microcore" thing: you could be right, since I 
noticed that many files which used to be in /boot now are gone, and they 
have possibly been linked into the lilo executable. In 
particular, /etc/lilo.conf.example mentions that now boot.b is linked 
directly into the /sbin/lilo binary. So, the LILO executable (the 
program the user runs after installing a new kernel image) might very 
well be a sort of hybrid.
Regarding the binary blob, however, I think your fears are not justified: 
there are no binary files inside the LILO source tarball, so everything 
must be built from sources one way or another. (Compare this with, for 
example, the nvidia-drivers, which instead contains lots of binary 
executable and object files - it's actually a .run file, a sort of mix 
between a shell script and a .tgz archive, which in turn contains the 
binary blobs, most notably the infamous nv-kernel.o).

After a brief look at the LILO Makefile, my understanding is that the 
parts which make up what you call the "microcore" (eg, the mbr, the 
various stages of the loader and other bootloader pieces) are built from 
assembly (.S) source files, using gcc -E, as86 and ld86 (the last two 
are from the bin86 package, which LILO depends upon).

So, while it might be difficult to understand all the internal trickery 
employed by the LILO executable behind the scenes when it runs, it 
certainly can't be likened to nvidia-like binary blobs, since here 
everything is built from sources, and certainly qualifies (IMHO at 
least) as "free software" (portage lists the LILO license as BSD GPL-2).

FWIW, here's my understanding of what /sbin/lilo does:

- if not already done, install suitable mbr and first and second stage 
loaders (probably reading them from somewhere inside the "microcore" and 
writing the raw disk sectors in place); note that this is similar to 
what grub-install (or the equivalent command in the GRUB interactive 
shell) does;

- create or update the so-called "map file", which lists where the 
various parts of the kernel are located on the disk, so that at boot 
time the loader can find them, load them into memory and finally run the 
kernel. The map is needed because, as you probably know already, the 
LILO loader is not able to read a file system, so it needs to have a 
lower level physical map of the disk sectors where the kernel file 
resides. The GRUB loader, OTOH, is able to understand and read from the 
most popular filesystems, so it does not need any map and its loader can 
literally read the kernel file from /boot (or wherever it is) and thus 
autonomously do all the work at boot time.

I hope the above is (mostly) correct and that helps a bit.

> I decided it was better to spend
> my time learning it than trying to trace down and figure out all the
> ins and outs of the LILO thing to my satisfaction, so that's exactly
> what I did, and indeed, I AM rather happier with GRUB, now that I
> actually took the time to learn how to work with it.

I was once a LILO-only user (mostly because GRUB was not popular when I 
first started using linux, so I simply stayed with LILO), but I must 
admit that I'm slowly migrating to GRUB. The great feature is (among 
other things) the ability to fully edit the command line before booting, 
which gives you more control than LILO over the boot process.

> FWIW, now I'm looking at LinuxBIOS, which I've already verified IS
> known to work on my mobo. 
>[cut]
> As I understand it now, I can use GRUB as the payload (making the grub
> first stage what amounts to a second stage after the LinuxBIOS), or
> one of the two options that normally come with LinuxBIOS, or even load
> a shrunken Linux kernel with just enough functionality to read the
> main kernel off the disk and kexec into it.
> [cut]
> Still, it might be a year or two, but I'll probably do it eventually,
> thus ridding my system of yet one more proprietary software (firmware)
> bit. 

This sounds really interesting and promising. I wonder how they can do "3 
seconds from power-on to Linux console". Even if the LinuxBIOS loads 
straightly a kernel as the payload, the kernel still takes more than 3 
seconds to initialize...this alone would be a good enough reason to do 
the switch! I hope you eventually succeed in the task.
-- 
gentoo-amd64@gentoo.org mailing list