|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] RFC/Patch: Support for other bootloaders
> > Did you try using mbootpack for this? (I haven't tested
> its output with
> > PXELinux, so I don't know if it would work.)
>
> No. This is the first I've heard of it.
>
> Given the two implementations, let's compare and discuss...
>
> My objective was to try to use the Linux bits as-is and to have Xen
> recognize that it is not loaded via GRUB (are there any other
> non-GRUB-related multi-boot implementations?).
kexec supports multiboot (admittedly thanks to a patch from us).
> As you can see, the
> changes required for Xen to recognize the parameters as passed out of
> Linux's setup.S are not very complicated. Figuring out where
> everything
> is is the tough part.
>
> I'm not attached at all to necessarily reach into a Linux
> build tree to
> extract a built setup and bootsect. I just think this is the easiest
> way to do it. x86 BIOS code is just icky and so I'd like to
> be able to
> avoid having to maintain or even change it. I think it's easier to
> have Xen get data out of boot_params.
As I recall, mbootpack uses Linux's x86 BIOS code too, so this shouldn't
be an issue.
> So, what I think it boils down to is whether Xen should accept
> parameters passed into it in Linux-style boot_params array, or only
> accept parameters in GRUB format.
I can't see any obvious advantage over the mbootpack approach, and that
has the advantage of being simpler and doesn't require making Xen
understand another boot parameter format.
Is there a downside I haven't spotted?
Ian
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
|
|