[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 05/10] libxl: synchronise configuration when we hotplug a device
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |