RFC: meta-bootlace (bootloader management layer)

[Peter Seebach <peter.seebach@windriver.com>]

If a system is up for a while, you might want to issue kernel patches. For
desktop distributions, this is pretty easy and reasonably well-understood;
there's a grub config file somewhere, you modify that, you reboot, everything
is good.

For embedded systems with bootloaders that aren't grub, or are grub but in a
configuration where the partition it loads kernels from isn't usually mounted,
it's not quite so easy. Worse, if you support a range of embedded boards, you
don't even have a specific single bootloader in mind; you have a large range
of bootloaders that you might need to deal with.

Bootlace is an attempt to provide a reasonably simple and fairly minimal
abstraction layer over the most commonly-used functionality: "I have a new
kernel, I want the next boot to use it." The idea is that a BSP can select a
backend that suits its design or configuration, and then that backend does
the actual heavy lifting, but everything else (such as a kernel postinst
script) just sees a fairly generic interface that doesn't require any specific
knowledge of the BSP.

I've put up the current tree in contrib:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=seebs/meta-bootlace

The only actually-working backend right now is specific to the way one of our
default install targets uses grub-efi, where the system boots from the kernel
installed as "vmlinuz" on a separate FAT32 partition that isn't normally
mounted while the system is running. The default backend just helpfully
prints a diagnostic saying that it can't actually change what kernel gets
selected.

We'd like to see this considered for inclusion in oe-core, once it has some
more backends. (In particular, once it has a grub backend, it could in
principle replace the existing kernel-grub bbclass.)

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.