WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

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

To: "Yang, Fred" <fred.yang@xxxxxxxxx>
Subject: [Xen-ia64-devel] RE: RE: [PATCH] Patch for loading module
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Wed, 21 Sep 2005 10:33:20 -0700
Cc: Brett Johnson <brettj@xxxxxxxxxxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 21 Sep 2005 17:36:15 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWzXYv7z4QSY3opQG+1Md0Pqmu3kALcs/xQAABlDBA=
Thread-topic: RE: [PATCH] Patch for loading module
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
> 

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

<Prev in Thread] Current Thread [Next in Thread>