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
xen4elilo.patch
Description: xen4elilo.patch
elilo-3.4.11.xen.patch
Description: elilo-3.4.11.xen.patch
elilo.README
Description: elilo.README
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home