Backward compability issue is only happened on "deployed" product, not
the "in development" project as xen/ia64.
Why need so much "options"?
Magenheimer, Dan (HP Labs Fort Collins) wrote:
> Well, so far the community is overwhelmingly in favor of B...
> Which is OK with me. I've come around to being OK with this
> after thinking on it overnight. I was uncomfortable with
> losing the backward compatibility, but if this is going
> to happen, now is the best time to do that while Xen/ia64
> has few users.
> One other thought I had overnight though:
> Both the domain0 image and the initrd image could be
> considered parameters to Xen. So suppose that "initrd="
> and "module=" are simply aliases for each other and the
> first two files specified as either module or initrd
> are passed (in order) as parameters to Xen. This would
> not only be backwards-compatible with existing Xen elilo.conf
> files, but would be more compatible with grub. So
> all of the following do the right thing:
> # choice A
> initrd=xenlinux # backward compatible
> #no initrd
> # choice B
> # grub and Xen/x86 compatible
> #no initrd
> # grub and Xen/x86 compatible and probably
> # the best to document for Xen/ia64?
> What do you think?
>> -----Original Message-----
>> From: Xu, Anthony [mailto:anthony.xu@xxxxxxxxx]
>> Sent: Monday, September 05, 2005 10:19 PM
>> To: Magenheimer, Dan (HP Labs Fort Collins); Yang, Fred
>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [PATCH] Patch for loading module[2of2]
>>>> Elilo is a gerernal OS loader,it doesn't and doesn't need to know
>>>> presence of domain0, For elilo, xen.gz is a OS kernel, initrd=
>>>> it's Os's initial ramdisk, module= is Os's parameter, we should
>>>> keep all this meaning, we shouldn't make elilo special just for
>>> Yes, module= is OS's parameter, but domain0 is not
>>> really a parameter.
>> From the view of Elilo, xen is an OS, domain0 is a parameter to xen.
>> As far as how to handle this parameter, it's up to xen.
Xen-ia64-devel mailing list