[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller

On Fri, May 22, 2015 at 5:21 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
> On 05/21/2015 07:07 PM, George Dunlap wrote:
>> We have several outstanding patch series which add devices that have
>> two levels: a controller and individual devices attached to that
>> controller.
>> In the interest of consistency, this patch introduces a section that
>> sketches out a template for interfaces for such devices.
>> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
>> ---
>> CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
>> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
>> CC: Juergen Gross <jgross@xxxxxxxx>
>> CC: Chun Yan Liu <cyliu@xxxxxxxx>
>> CC: Olaf Hering <olaf@xxxxxxxxx>
>> So, this is definitely RFC -- I tried to spec things out in a way that
>> made sense, but I often just chose something that I thought would be a
>> sensible starting point for discussion.
>> This spec looks a lot more like the PVUSB spec than the PVSCSI spec,
>> in part because I think the PVUSB spec has already had a lot more
>> thought that's gone into it.
>> A couple of random points to discuss:
>> * Calling things "controllers", using <type>ctrl for the device name,
>>    and using "ctrl" as the field name for the devid of the controller
>>    in the individual devices.
> Hmm, what about "device group" (<type>devgoup)? In the scsi world
> "controller" would be one level higher in the hierarchy. And the scsi
> controller is at least visible in the configuration syntax "h:c:t:l".
> Using "controller" for the "c" in this item and for the "t" internally
> could lead to confusion.

OK, so I looked it up[1] and the full address seems to be:
* adapter number / host
* channel number / bus
* id number / target

In which case, "controller" would correspond to "adapter / host", right?

In the vscsi world, what levels of what can you make?  I know you
mentioned before that some devices have multiple LUNs, and those need
to be grouped together, with the same LUNs as they do on real
hardware, to work properly -- is that right?

The USB case actually has something somewhat similar:
* USB controller
* USB bus
* USB device
* USB function

So far, there's not really a controller/bus distinction: each
controller has exactly one bus.  When we assign a USB device to a bus,
we automatically go through and assign each function fo that device

Would it make sense to treat vscsi the same way -- i.e., to make a
"bus", and then attach "targets"s to it, and have the LUNs for any
given target automatically assigned when the target is assigned?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.