Re: [Xen-devel] [PATCH v5 3/5] libxl: add support for vscsi

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-05-15 at 11:35 +0200, Juergen Gross wrote:
> On 05/15/2015 10:47 AM, Ian Campbell wrote:
> > On Fri, 2015-05-15 at 07:58 +0200, Olaf Hering wrote:
> >> On Fri, May 15, JÃrgen Groà wrote:
> >>
> >>> Multi-LUN devices do exist and they are required to be presented as
> >>> those to the guest.
> >>
> >> Ok, this means we need the bus concept. I will see if the API for
> >> add/remove can be changed that only devices get passed to the libxl.
> >
> > Does a multi-LUN device require it's own bus or something?
> >
> > Or do the LUN numbers need to be passed through to the guest because
> > things get upset otherwise?
> >
> > IOW why does multi-LUN imply multi-bus, and even if so why does that
> > need to be exposed to the user?
> 
> These are e.g. RAID-systems or tape libraries. In most cases one LUN
> is a control LUN via which the other LUNs can be configured and/or
> administrated. This implies that all of those LUNs have to share the
> same target and they need to have the same LUN numbers in the guest as
> on the real device.

That makes sense, thanks.

So it seems we do need to expose some concept of the bus itself to
users.

My preference would be for the API for such devices (currently USB and
PVSCSI) to have broadly speaking the same shape, much like how the API
for the existing "busless" devices all look mostly the same.

(NB: Lets ignore the fact for now that PCI is in the wrong bucket...)

I'd like to start with seeing an expanded version of the comment in
libxl.h which begins:

/*
 * Devices
 * =======

which covers this new style API alongside the existing one and sets out
the expected pattern of naming (both struct and function) in the same
way.

Ian.


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