From mboxrd@z Thu Jan  1 00:00:00 1970
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Subject: Re: [PATCH] Support user domain create extensions
Date: Tue, 20 Nov 2012 07:53:33 +0100
Message-ID: <50AB28ED.5040703@ts.fujitsu.com>
References: <7c02a22ef82161c3930f.1352886775@nehalem1>
	<20646.24679.998078.183038@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20646.24679.998078.183038@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

Am 16.11.2012 16:48, schrieb Ian Jackson:
> Juergen Gross writes ("[Xen-devel] [PATCH] Support user domain create extensions"):
>> This patch supports arbitrary extensions to xl create by being able
>> to specify a script which is run at domain creation. The script is
>> specified in the xl config file and will be started at domain
>> creation with following parameters:
>>
>> <script>  restore|create<domid>  <path of config file>
>
> Thanks.  I think this is a reasonable idea.
> I wonder if this might be profitably moved down into libxl.

Okay, I'll try it.

>
> Also the interface needs work.  At the very least there needs to be a
> corresponding "destroy" script invocation.

Sounds reasonable.

>
>> To be able to use non-standard devices a new device class "NSTD" is defined.
>> The xl framework will remove all NSTD devices when destroying a domain.
>
> Did I miss the implementation of this ?

I haven't tested it myself. I thought libxl will cycle through all known
device classes in the xenstore modifying the backend state of the devices
connected to the domain. This should do the job. Have I missed something?

>
>> +const char *libxl_userdata_path(libxl_ctx *ctx, uint32_t domid,
>> +                                const char *userdata_userid,
>> +                                const char *wh)
>
> I don't think this is correct.  We shouldn't be exposing the userdata
> path like this.  But anyway if we are moving this into libxl then the
> config file won't be exposed to the script anyway.
>
> What does your script need the config file for ?  Writing a separate
> parser for it is clearly a mistake...

We want to be able to:
- specify parameters for our NSTD device per domain
- make sure a domain with a NSTD device is started in the correct cpupool
   (license restriction)

So we need a way to access domain configuration parameters. There are
some other ways to do this, using the config file was the most simple one.
I could think of following alternatives:

- add a new xl subcommand to get a configuration parameter of a domain, e.g.
   xl domain-par <domain> <parameter>

- specify parameters of interest in the xl config file. Those parameters will
   be made available to the script via shell variables. Something like:
   domain_create_script_pars="cpupool nstd_device"
   leading to shell variables XLPAR_cpupool and XLPAR_nstd_device to be set to
   the correct values when invoking the script.


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html