Re: [Xen-devel] [PATCH v1 05/10] libxl: synchronise configuration when we hotplug a device

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Jul 17, 2014 at 12:44:43PM +0100, Ian Campbell wrote:
> On Wed, 2014-07-16 at 18:12 +0100, Wei Liu wrote:
> > > > As we don't have a JSON config file for libxl toolstack domain
> > > > (currently Dom0) we need to skip JSON manipulation for it.
> > > 
> > > How hard would it be to create a stub/stunt JSON for dom0 when we notice
> > > it is missing? Or from e.g. xencommons perhaps?
> > > 
> > 
> > We need to determine:
> > 1. when / where to generate such thing (xencommons?)
> > 2. what to put in it
> > 
> > I have yet had answers for #2. The simplest version can be "{}" I think.
> > That is an empty configuration that every fields gets the default value.
> > But we probably need more than that.
> 
> I think you would want at least a name and perhaps a uuid? And cinfo
> type == PV.
> 
> Device arrays are all empty at start of day.
> 
> Some of the stuff about target and maxmem you could perhaps infer at
> start of day?
> 

UUID (Dom0 doesn't seem to have one), name and memory targets can all be
pulled from xenstore when they are required.

And it occurs to me as I discovered Dom0 doesn't have UUID that we need
to special-case reading / writing of Dom0's JSON config. That's because
all other guests' JSON config are to be named with UUID and domain id.
How annoying. :-(

I would like to put as few things as possible in the stub because there
doesn't seem to be a way to conveniently generate a valid JSON config
for Dom0. Will you be against the idea of having 'xl generate-dom0-json'
in xl to do that? Otherwise we have to basically generate a
semi-handcoded stub in xencommons, or even a hardcoded stub.


> > > > +    DEVICE_ADD_JSON(vtpm, vtpms, num_vtpms, domid, &vtpm_saved,
> > > 
> > > The second and third of these arguments could be derived from the first.
[...]
> > > How close to being possible is it to do this as a proper helper function
> > > which takes a size_t and a bunch of fn pointers with void where the type
> > > would be?
> > > 
> > 
> > We need to know the type of this structure otherwise we don't know what
> > *_copy function to call. Sadly there's no way to pass in type information
> > in C in runtime.
> 
> You could pass a copyfn as a function pointer with a void * argument for
> the object to a helper function which doesn't need the specifics and
> then have a macro which simply defines the type safe wrappers around
> that. ISTR thinking  that the helper would need a sizeof passing to it
> as well for the realloc.
> 

I see. I will try to go with this approach.

Wei.

> Ian.

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