Re: [Xen-devel] [PATCH v3 4/7] xl/libxl: add a blkdev_start parameter

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-04-20 at 15:04 +0100, Stefano Stabellini wrote:
> On Tue, 17 Apr 2012, Ian Jackson wrote:
> > Stefano Stabellini writes ("[Xen-devel] [PATCH v3 4/7] xl/libxl: add a 
> > blkdev_start parameter"):
> > > Introduce a blkdev_start in xl.conf and pass it to
> > > libxl_domain_create_* and all the way through libxl_run_bootloader and
> > > libxl__device_disk_local_attach.
> > 
> > Surely this should be passed in the domain config structure rather
> > than being an adhoc parameter.
> 
> I don't think so, see below.
> 
> > If the problem with that is that it really ought to be host-global and
> > come from xl.conf, then perhaps we need another config struct.  But
> > really I think that's overkill.  There is nothing wrong with taking
> > parameters from xl.conf and putting them in the libxl domain config.
>  
> Another host-global config struct is definitely overkill, but we cannot
> really pass this parameter in the libxl domain config, because this
> option has nothing to do with the domain config.
> It would be confusing and incorrect.

You could argue that "domain config" was actually as much about details
on how to build the guest as it was about the "domain config" as such.
Members of that struct like the device model version, xsm ssid, disable
migrate, cpupool id, etc could all be argued to fit into the same "grey
area".

In any case adding a new parameter for each global variable which a
function happens to need to look at is not a good API.

If you don't like domain config as a home for this then the "overkill"
option of a new config struct seems like a reasonable answer. It's
possible that it only seems like overkill now because we don't have many
of such things, but we might be thankful for it when we (inevitably)
have half a dozen.

Alternatively a variable in the ctx and functions to set/get it might
work, but that seems like a worse version of the global config struct to
me...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel