[Xen-ia64-devel] RE: RE: [PATCH] Patch for loading module

["Yang, Fred" <fred.yang@xxxxxxxxx>]

Attached is xlilo.efi binary.
Elilo.3.5-pre1 doesn't work (described in the previous mails) on EL4
disk no matter it is  directly pulling binary or build from source.  it
failed on mounting root fs and a bug report has been filed in bugzilla.

Brett, 
Please pull the elilo patch.
Thanks,

-Fred

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> Hi Fred/Anthony --
> 
> Thanks for continuing to work on this.  There's probably
> no reason for every developer to go through the recipe
> to rebuild "xelilo.efi" and I don't particularly want to
> do it again (for the third time) myself.  So could you
> provide an ftp address from where I can download a known
> working xelilo.efi?
> I will check in both the patch info and the working
> xelilo.efi (if it is not too big) into the tree.
> 
> Also, I believe Brett asked for a patch relative to 3.5.xxx?
> 
> Thanks,
> Dan
> 
>> -----Original Message-----
>> From: Yang, Fred [mailto:fred.yang@xxxxxxxxx]
>> Sent: Wednesday, September 21, 2005 11:27 AM
>> To: Matt Chapman; Magenheimer, Dan (HP Labs Fort Collins)
>> Cc: Xu, Anthony; Brett Johnson; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [PATCH] Patch for loading module
>> 
>> Attached please find Elilo patches to both elilo-3.4-11 and Xen-ia64
>> The patches support following elilo.enty as well as backward
>> compatible to elilo-3.4-11
>> The test has been done upto loading initrd, but obviousely it
>> doesn't match the domain image 
>> 
>> image=XenoLinux.uncompressed
>>       <==
>> Domain0 uncompressed image
>>                         label=xen
>>                         vmm=xen.gz
>> <== Xen compressed image
>>                         initrd=initrd-2.6.9-5.7.EL.img
>> <==  initrd file to match "image"
>>                         read-only
>>                         append="com2=57600,8n1 console=com2
>> sched=bvt -- nomca console=ttyS1,576 00 console=tty0 root=/dev/sda3"
>> -Fred 
>> 
>> -----Original Message-----
>> From: Matt Chapman [mailto:matthewc@xxxxxxxxxxxxxxx]
>> Sent: Tuesday, September 06, 2005 8:38 PM
>> To: Magenheimer, Dan (HP Labs Fort Collins)
>> Cc: Yang, Fred; Xu, Anthony; Brett Johnson;
>> xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-ia64-devel] PLEASE REPLY and RE: [PATCH] Patch for
>> loading module[2of2] 
>> 
>> I like "hypervisor=" or "hvimage=", or how about about "vmm=" or
>> "preload=" if you don't want to use the word hypervisor ?  This
>> functionality will be useful for other hypervisors too (such as
>> vNUMA), so I'd rather not call it "xenimage"...
>> 
>> Matt
>> 
>> 
>> On Tue, Sep 06, 2005 at 10:24:58AM -0700, 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

Attachment: xlilo.efi
Description: xlilo.efi

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel