[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 * 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? 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? -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |