Re: [PATCH v8 3/5] libxl: add support for vscsi

[Olaf Hering <olaf@aepfle.de>]

On Tue, Feb 16, Ian Jackson wrote:

> Olaf Hering writes ("Re: [PATCH v8 3/5] libxl: add support for vscsi"):
> > On Mon, Feb 15, Ian Jackson wrote:
> > > One reason you might define a virtual controller with no devices yet
> > > is so that you have a stable and pre-expected device path for any
> > > actual targets you choose to hotplug later.
> > 
> > Would it be acceptable to reuse the devid as the "group index"?
> > The various vdev in vscsi=['pdev,vdev'] will be assigned to the same
> > vscsictrl if the host part in host:chn:target:lun matches. Right now an
> > empty vscsictrl has no property to store the "host" part. This could be
> > handled by either reusing devid, or by introducing a new xenstore
> > property such as "libxl_vscsictrl_index". The value itself has no
> > meaning other than being an index or label.
> 
> I haven't been following this design in detail, but: why is the
> vscictrl `host' number not part of the xenstore path for the
> controller, which in turn contains the devices ?

Thats exactly what I'm asking, see patch #4 of this series. Each
libxl__device has a devid, which is essentially just an unique counter.
A vscsictrl is a libxl__device, a vscsidev is something below a
vscsictrl. To describe which vscsidev belongs to which vscsictrl the
hctl notation is used. The frontend uses 'ctl', the toolstack 'h'.
The hctl is stored in vscsi-devs/N/v-dev. An empty vscsictrl has no
vscsidev and as a result no 'v-dev' to indicate which 'h' it represents.

During scsi-attach the code has to collect a list of existing
vscsictrls. If an existing vscslctrl with the requested group number 'h'
exists its clear where the new vscsidev belongs to. Otherwise a new
empty vscsictrl has to be created. It needs some property to hold 'h'.
This can be either the devid, or a new xenstore property.


I will use a new xenstore property.

Olaf