Re: [PATCH v2] libxl: Support backend domain ID for disks

[Ian Jackson <Ian.Jackson@eu.citrix.com>]

Daniel De Graaf writes ("[PATCH v2] libxl: Support backend domain ID for disks"):
> Allow specification of backend domains for disks, either in the config
> file or via xl block-attach. This functionality was supported in xend
> (via an optional command line parameter to block-attach), so should also
> be supported with libxl.
> 
> In order to support named backend domains like network-attach, a valid
> libxl_ctx must now be passed to xlu_cfg_init.

I've been thinking about this and I'm afraid I've come to the
conclusion that the way your new API specifies backend domains is not
the way I think it should be done.

In particular, I think translating the config file from a source text
into an idl configuration structure shouldn't depend on looking up
information like domids.  (The same would be true of DNS names, or
other runtime lookups.)  So I think the backend domain _name_ should
be in the IDL structure.

But of course it should also be possible to specify a domid.

I can think of three (at least superficially) plausible ways to define
this API:

1. The backend domain is specified as a string.  If specifying a domid
   is desired, the string is the domid number in ascii.  Domains whose
   names are entirely valid numbers according to strtoul(,,0) cannot
   be specified as backends by name (or should perhaps be prohibited
   entirely - xl can't handle them anyway).

2. The IDL contains both a string and a number.  If the string is
   provided, it is used; otherwise the number is used.

3. The IDL contains a variadic "domspec" structure which allows the
   domain to be specified (a) not at all (b) as a domid (c) as a
   domain name (d) as a uuid.

Of these I think 3 is probably overkill and either 1 or 2 is
acceptable and I have a marginal preference for 2.

Before you implement any of this I think we should agree whether my
qualm about domain name lookups during config parsing is justified,
and what the right API is.

NB that this complaint does seem perhaps contrary to my intent to add
a libxl context to libxlu parsing calls.  But, having thought about
it, this libxl context should be a "dummy" one which can be used for
memory allocation and logging but which does not support actual Xen
functionality.

Thanks, and sorry to block your useful new functionality on cans of
works.

Ian.