[OE-core] RFC: meta-bootlace (bootloader management layer)
Peter Seebach
peter.seebach at windriver.com
Wed Jun 17 22:08:19 UTC 2015
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.
More information about the Openembedded-core
mailing list