From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH RFC v1] libxl: Introduce a template for devices with a controller Date: Wed, 27 May 2015 12:09:30 +0200 Message-ID: <556597DA.6090306@suse.com> References: <1432228052-15667-1-git-send-email-george.dunlap@eu.citrix.com> <555EAEAD.2040103@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Olaf Hering , Wei Liu , Ian Campbell , Chun Yan Liu , "xen-devel@lists.xen.org" , Ian Jackson List-Id: xen-devel@lists.xenproject.org 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 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 >>> --- >>> CC: Ian Campbell >>> CC: Ian Jackson >>> CC: Wei Liu >>> CC: Juergen Gross >>> CC: Chun Yan Liu >>> CC: Olaf Hering >>> >>> 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 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" (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