All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2] libxl: Support backend domain ID for disks
Date: Tue, 09 Oct 2012 14:41:16 -0400	[thread overview]
Message-ID: <50746FCC.9020705@tycho.nsa.gov> (raw)
In-Reply-To: <20596.16757.874363.819950@mariner.uk.xensource.com>

On 10/09/2012 11:23 AM, Ian Jackson wrote:
> 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.
> 

I assume that this change would also apply to vfb, vkb, nic, and any new
devices that allow backend domains to be specified (i.e. vtpm). Currently,
the domains have to be specified by name in xl's config file, but I think
that allowing domid there in addition is a good idea.

Method (2) is also simpler for backwards compatibility as it allows the
existing backend_domid fields to remain, supplemented by an entry like
backend_name - so that's my preference.

-- 
Daniel De Graaf
National Security Agency

      reply	other threads:[~2012-10-09 18:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-06 21:51 [PATCH RFC/for-4.2?] libxl: Support backend domain ID for disks Daniel De Graaf
2012-08-07  9:36 ` Ian Campbell
2012-08-07 10:38   ` Ian Jackson
2012-08-07 13:56   ` Daniel De Graaf
2012-08-31  8:04 ` Ian Campbell
2012-09-05 17:05   ` [PATCH v2] " Daniel De Graaf
2012-09-06  7:26     ` Ian Campbell
2012-09-06 12:24       ` Daniel De Graaf
2012-10-09 15:23     ` Ian Jackson
2012-10-09 18:41       ` Daniel De Graaf [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50746FCC.9020705@tycho.nsa.gov \
    --to=dgdegra@tycho.nsa.gov \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.