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

Re: [Xen-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu [and 1 more messages]



On Wed, 2014-07-02 at 23:56 -0600, Chun Yan Liu wrote:
> 
> >>> On 7/2/2014 at 11:17 PM, in message
> <21428.8829.273127.394928@xxxxxxxxxxxxxxxxxxxxxxxx>, Ian Jackson
> <Ian.Jackson@xxxxxxxxxxxxx> 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.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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