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. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
