[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
George,
I'm on vacation this and the next week with only limited email access.
So please don't expect fast reaction on any further questions during
this time. :-)
On 05/26/2015 07:56 PM, George Dunlap wrote:
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
* LUN
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?
Not all of the devices have this requirement, but some.
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
individually.
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?
As long as it is still possible to assign individual LUNs as well.
If dom0 is controlling e.g. a RAID system you might want to assign
one LUN of a target to domU A and one LUN of the same target to domU B.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
