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

Re: [Xen-devel] [PATCH V5 29/32] xl: use "libxl-json" format



On Tue, 2014-06-03 at 11:02 +0100, Wei Liu wrote:
> On Mon, Jun 02, 2014 at 05:30:23PM +0100, Ian Campbell wrote:
> > On Sun, 2014-06-01 at 20:37 +0100, Wei Liu wrote:
> > > On Tue, May 20, 2014 at 03:23:26PM +0100, Ian Campbell wrote:
> > > [...]
> > > > > @@ -1787,13 +1770,10 @@ static int handle_domain_death(uint32_t 
> > > > > *r_domid,
> > > > >          break;
> > > > >  
> > > > >      case LIBXL_ACTION_ON_SHUTDOWN_RESTART_RENAME:
> > > > > -        reload_domain_config(*r_domid, config_data, config_len);
> > > > >          restart = 2;
> > > > >          break;
> > > > >  
> > > > >      case LIBXL_ACTION_ON_SHUTDOWN_RESTART:
> > > > > -        reload_domain_config(*r_domid, config_data, config_len);
> > > > 
> > > > Why is it not equally necessary to reload the JSON config at this point
> > > > if it exists?
> > > > 
> > > 
> > > Because domain configuration is loaded in the caller of
> > > handle_domain_death now.
> > 
> > OK. Is there any way that could be refactored into a separate patch to
> > make this one simpler to reason about?
> > 
> 
> The purpose of reload_domain_config is to load the "xl" file (in fact
> the saved domain config) from libxl private data store. After we have
> our API to retrieve domain configuration in libxl I don't see the need
> for it anymore. And this change needs to come with the introduction of
> "libxl-json" file, a separate change is not very feasible IMHO.

If it's not possible to just replace the reload_domain_config with a
call to the retrieval function and then refactor later then that's fine.

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®.