[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd
From: |
Ian Campbell |
Subject: |
Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu [and 1 more messages] |
Date: |
Thu, 3 Jul 2014 10:08:46 +0100 |
On Wed, 2014-07-02 at 23:56 -0600, Chun Yan Liu wrote:
>
> >>> On 7/2/2014 at 11:17 PM, in message
> <address@hidden>, Ian Jackson
> <address@hidden> wrote:
> > Ian Campbell writes ("Re: [RFC PATCH V3 1/2] xen: pass kernel initrd to
> > qemu"):
> > > On Mon, 2014-06-23 at 15:22 +0100, Ian Jackson wrote:
> > > > If we are going to do this then I think the kernel, cmdline and
> > > > ramdisk (and bootloader) parameters shoudl be moved into the main part
> > > > of the domain_build_info struct. This will involve a compatibility
> > > > layer: temporarily (for at least one release)
> > >
> > > I don't think so -- we would need to retain it forever or at least until
> > > some sort of "API break" event. We still guarantee that applications
> > > using the 4.2 API will be supported.
> >
> > Yes. Sorry, I meant that the compatibility should be retained for
> > some considerable time. So for now we should honour all the existing
> > config struct members plus also the new cmdline member which should
> > IMO be in the main part of the struct and not inside pv.
>
> No new member created, it's always 'cmdline' in libxl_domain_build_info.
> 'root' and 'extra' and new 'cmdline' are only words to config file.
>
> Before, in libxl_domain_build_info, there are only
> u.pv.kernel|cmdline|ramdisk,
> now since both PV and HVM support them, in theory we should move them
> to main part, but considering the compatibility issue, I'm not sure which one
> is better?
> 1. add u.hvm.kernel|cmdline|ramdisk and add hvm processing only (as in V2)
> 2. add u.kernel|cmdline|ramdisk (since now both PV and HVM have these) but
> keep u.pv.kernel|cmdline|ramdisk, add hvm processing, add pv processing
> u.kernel|cmdline|ramdisk too so that new users could use new APIs. (as in
> V3)
>
> Your suggestions?
Something like 2 is the correct thing.
The final b_info struct should have the new fields:
b_info->{kernel,cmdline,ramdisk}
and these existing ones:
b_info->u.pv.{kernel,cmdline,ramdisk}
In libxl__domain_build_info_setdefaults you should then do, iff type ==
PV:
if (!b_info->kernel)
b_info->kernel = b_info->u.pv.kernel;
b_info->u.pv.kernel = NULL;
likewise for ramdisk and cmdline.
and then all of the remaining library code should use b_info->kernel
exclusively.
Ian.