[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RESEND v3 1/2] libxl: postpone backend name resolution
On Thu, 2013-03-14 at 14:23 +0000, Daniel De Graaf wrote: > This adds a backend_domname field in libxl devices that contain a > backend_domid field, allowing either a domid or a domain name to be > specified in the configuration structures. The domain name is resolved > into a domain ID in the _setdefault function when adding the device. > This change allows the backend of the block devices to be specified > (which previously required passing the libxl_ctx down into the block > device parser), and will simplify specification of backend domains in > other users of libxl. please can we get a #define LIBXL_HAVE_DEVICE_BACKEND_NAME (or something similar) in libxl.h so applications can tell that it is safe to use this. > Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> > Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> > Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> > Cc: Ian Campbell <ian.campbell@xxxxxxxxxx> > > --- > > This patch does not include the changes to tools/libxl/libxlu_disk_l.c > and tools/libxl/libxlu_disk_l.h because the diffs contain unrelated > changes due to different generator versions. > > docs/misc/xl-disk-configuration.txt | 12 +++++++++ > tools/libxl/libxl.c | 49 > ++++++++++++++++++++++++++++++++++++- > tools/libxl/libxl_types.idl | 5 ++++ > tools/libxl/libxlu_disk_l.l | 1 + > tools/libxl/xl_cmdimpl.c | 36 ++++++--------------------- > 5 files changed, 73 insertions(+), 30 deletions(-) > > diff --git a/docs/misc/xl-disk-configuration.txt > b/docs/misc/xl-disk-configuration.txt > index 86c16be..5bd456d 100644 > --- a/docs/misc/xl-disk-configuration.txt > +++ b/docs/misc/xl-disk-configuration.txt > @@ -139,6 +139,18 @@ cdrom > Convenience alias for "devtype=cdrom". > > > +backend=<domain-name> > +--------------------- > + > +Description: Designates a backend domain for the device > +Supported values: Valid domain names > +Mandatory: No > + > +Specifies the backend domain which this device should attach to. This > +defaults to domain 0. Specifying another domain requires setting up a > +driver domain which is outside the scope of this document. > + > + > backendtype=<backend-type> > -------------------------- > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c > index 73e0dc3..e442afc 100644 > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > @@ -1730,12 +1730,35 @@ static int libxl__device_nextid(libxl__gc *gc, > uint32_t domid, char *device) > return nextid; > } > > +/* backend domain name-to-domid conversion utility */ > +static int libxl__resolve_domain(libxl__gc *gc, const char *name) > +{ > + int i, rv; > + uint32_t domid; > + for (i=0; name[i]; i++) { > + if (!isdigit(name[i])) { > + rv = libxl_name_to_domid(libxl__gc_owner(gc), name, &domid); > + if (rv) > + return rv; > + return domid; > + } > + } What are the constraints on the names of domains? I suppose it is toolstack specific but the xl docs jsut say it has to be unique. I'd suggest a simple rule like they cannot start with a digit, that would make the loop in the above unnecessary. In any case the loop is a bit odd since AFAICT it will treat "123boo" as "boo", I think it should either treat the entire string as a name or a number. I think you should just move domain_qualifier_to_domid from xl to libxl and use that... > + return atoi(name); > +} > + > > /******************************************************************************/ > int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm) > { > + int rc; > if(libxl_uuid_is_nil(&vtpm->uuid)) { > libxl_uuid_generate(&vtpm->uuid); > } > + if (vtpm->backend_domname) { > + rc = libxl__resolve_domain(gc, vtpm->backend_domname); > + if (rc < 0) > + return rc; > + vtpm->backend_domid = rc; > + } How about rc = libxl__resole_domain(gc, vtpm->backend_domname, &vtpm->backend_domid); if (rc < 0) return rc; ? Then the if (...) which is repeated could be in the function and it'd be easier to keep the logic the same for all of them. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |