> > Just something to consider, provided the issues with multiboot get > > resolved: > > > > If you want to boot Xen you actually use the multiboot protocol, the > > last PVH > > boot patches had borrowed ideas from Multiboot to add an entry to > > Linux, only > > it was Xen'ified. What would be Multiboot 2 seemed flexible enough to > > allow all > > sorts of custom semantics and information stacked into a boot image. > > The last > > thought I had over this topic (before giving up) was-- if we're going > > to add > > yet-another-entry (TM) why not add extend Mulitiboot 2 protocol with > > the > > semantics we need to boot any virtual environment and then add > > Multiboot 2 > > support entry on Linux? We could redirect any custom boot mechanism > > then to > > just use that given its flexibility. > > > > Luis > > Multiboot has a fundamentally broken assumption, which is to do certain work > for the kernel in the > bootloader. This is fundamentally a bad idea, because you always want to do > things in the latest > step possible during the boot process, being the most upgradeable, and have > the interface as > narrow as possible. > > Therefore, using Multiboot is actively a negative step. It is declared an > "Open Standard" but > anything can be such declared; it really is a claim that "everything should > work like Grub."
Thanks Peter and Luis for comments. Chao