[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] PLEASE REPLY and RE: [PATCH] Patch for loading module[2of2]


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Xu, Anthony" <anthony.xu@xxxxxxxxx>, "Brett Johnson" <brettj@xxxxxxxxxxxxxxxxxxxxx>
  • From: "Yang, Fred" <fred.yang@xxxxxxxxx>
  • Date: Tue, 6 Sep 2005 20:16:39 -0700
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 07 Sep 2005 03:14:31 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcWYaSAKDEpFITOYRmOMPwJnp5q9pQAADjIQADg3V1AALzs7IAAA1IBAAJG2/gAAqDjkoALc+tCgAAoHLKAAAPRkgAAApnnQAAFGaiABWEA+IAA0WXZQAACwtOAAMRIlgAAIVoZwAByzCLAAAOI5oAAQ/UWwAAWGZDAAAhkicAADG+XQABI6oqAAB7VEQAAAtlsgABUkDiA=
  • Thread-topic: [Xen-ia64-devel] PLEASE REPLY and RE: [PATCH] Patch for loading module[2of2]

Anybody knows which elilo.efi version will be released with EL4?  It
seems base on version 3.4.

Elilo version 3.5 failed on booting EL4 for at least 3 different
platform for us!  Has anyone tried /elilo/elilo-3.5-pre1-ia64.efi
downloaded from
http://prdownloads.sourceforge.net/elilo/elilo-3.5-pre1-ia64.efi?downloa
d  (either source or binary) to boot EL4 kernel & disk?  We have tested
it to boot EL3 only and it failed with 3 systems running with EL4.

We will submit patch with enhancement with "vmmodule=" with current
elilo 3.4.11 version if version3.5 still fails to boot EL4.

-Fred

from Magenheimer, Dan (HP Labs Fort Collins) wrote:
> I just talked to Brett Johnson, the maintainer for elilo.
> My suggestion of having initrd= and module= be synonyms
> doesn't work well with the elilo parser.  However,
> he prefers a solution that AFAIK has not yet been proposed:
> 
> - Leave image= for the Linux kernel image.
> - Leave initrd= for the Linux kernel's initrd
> - Add a NEW keyword, xenimage=, to specify the xen binary.
> 
> He says that the module= proposal is already Xen-specific;
> he doesn't see any other uses for it on the horizon.  The
> term "module" is also very vague and doesn't describe what
> it is being used for.  So, he says, why not just be explicit
> that we are booting Xen and leave the image= and initrd=
> keywords with the same Linux meaning.  Thus:
> 
> label=xen
>   xenimage=xen
>   image=xenlinux
>   initrd=initrd.img
> 
> (and if we don't want to explicitly encode the term "Xen"
> in the keyword, we could use "hvimage=" or "hv=" or
> "hypervisor="** instead.)
> 
> Brett's solution seems the best to me.  It will also
> work quite nicely for a transparently paravirtualized
> system: If xenimage= is specified but the file is not
> found, just load and boot image= which will boot normal
> Linux.
> 
> Comments?
> 
> On a related note:  Anthony, Brett said that he would much
> prefer to see a patch against elilo v3.5-pre1 as there are
> additional bug fixes in that base.
> 
> Dan
> 
> ** probably don't want to use "hypervisor=" since the
> word has been trademarked by a certain big blue company :-)
> 
>> -----Original Message-----
>> From: Yang, Fred [mailto:fred.yang@xxxxxxxxx]
>> Sent: Tuesday, September 06, 2005 10:45 AM
>> To: Magenheimer, Dan (HP Labs Fort Collins); Xu, Anthony
>> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [Xen-ia64-devel] PLEASE REPLY and RE: [PATCH]
>> Patch for loading module[2of2]
>> 
>> 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
>>> image=xen
>>> initrd=xenlinux # backward compatible
>>> #no initrd
>>> 
>>> # choice B
>>> image=xen
>>> module=xenlinux
>>> initrd=initrd.img
>>> 
>>> # grub and Xen/x86 compatible
>>> image=xen
>>> module=xenlinux
>>> #no initrd
>>> 
>>> # grub and Xen/x86 compatible and probably
>>> # the best to document for Xen/ia64?
>>> image=xen
>>> module=xenlinux
>>> module=initrd.img
>>> 
>>> 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
>>>>>> xen.
>>>>> 
>>>>> 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
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.