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, 17 Jun 2015 13:28:24 +0200 Message-ID: <558159D8.1060509@suse.com> References: <1432228052-15667-1-git-send-email-george.dunlap@eu.citrix.com> <1434539195.13744.321.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434539195.13744.321.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , George Dunlap Cc: Ian Jackson , Olaf Hering , Wei Liu , Chun Yan Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 06/17/2015 01:06 PM, Ian Campbell wrote: > On Thu, 2015-05-21 at 18:07 +0100, 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. > > Chun Yan and Jeurgen: > > I was hoping we could come to some sort of agreement on this such that > it can be used as the basis for both the pvusb and pvscsi interfaces. As > such your feedback here is important... I already gave some feedback. As everything regarding this feedback has been discussed: Acked-by: Juergen Gross > >> >> 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. >> >> * I've said that having an index (port, lun, whatever) is optional. >> Do we want to make that requred? Do we want it to have a consistent >> name? In the case of emulated USB, we can't really specify to qemu >> what port the device gets attached to, so I'm tempted to say it's >> not required; but even there we could always give it a port number >> just for name's sake. >> >> * Naming sub-devices. We need to have a way to uniquely name both >> controllers and subdevices. Here I've said that we will have both >> ctrl and devid namespaces, mainly because in the >> previous point I opted not to require an index. Another option >> would be not to have another devid namespace, but to use >> as the unique identifier. (This would mean requiring >> the index/port/lun specification above.) >> >> * libxl_device__list listing devices across all controllers. I >> think this is the most practical thing to do, but one could imagine >> wanting to query by controller ID instead. >> >> Feedback welcome. >> --- >> tools/libxl/libxl.h | 46 ++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 46 insertions(+) >> >> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h >> index 2ed7194..d757845 100644 >> --- a/tools/libxl/libxl.h >> +++ b/tools/libxl/libxl.h >> @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); >> * >> * This function does not interact with the guest and therefore >> * cannot block on the guest. >> + * >> + * Controllers >> + * ----------- >> + * >> + * Most devices are treated individually. Some devices however, like >> + * USB or SCSI, inherently have the need to have "busses" or >> + * "controllers" to which individual devices can be attached. >> + * >> + * In that case, for each , there will be two sets of the >> + * functions, types, and devid namespaces outlined above: one based on >> + * '', and one based on 'ctrl'. >> + * >> + * In those cases, libxl_device_ctrl_ will act more or >> + * less like top-level non-bus devices: they will either create or >> + * accept a libxl_devid which will be unique within the >> + * ctrl libxl_devid namespace. >> + * >> + * Second-level devices which will be attached to a controller will >> + * include in their libxl_device_ a field called ctrl, which >> + * will be the libxl_devid of the corresponding controller. It may also >> + * include an index onto that bus, that represents (for example) a USB >> + * port or a SCSI LUN. >> + * >> + * These second-level devices will also have their own devid which >> + * will be unique within the devid namespace, and will be used >> + * for queries or removals. >> + * >> + * In the case where there are multiple different ways to implement a >> + * given device -- for instance, one which is fully PV and one which >> + * uses an emulator -- the controller will contain a field which >> + * specifies what type of implementation is used. The implementations >> + * of individual devices will be known by the controller to which they are >> + * attached. >> + * >> + * If libxl_device__add receives an uninitialized ctrl devid, it >> + * may return an error. Or it may (but is not required to) choose to >> + * automatically choose a suitable controller to which to attach the >> + * new device. It may also (but is not required to) automatically >> + * create a new controller if no suitable controllers exist. >> + * Individual devices should document their behavior. >> + * >> + * libxl_device_ctrl_list will list all controllers for the domain. >> + * >> + * libxl_device__list will list all devices for all controllers >> + * for the domain. The individual libxl_device_ will include >> + * the devid of the controller to which it is attached. >> */ >> >> /* Disks */ > > >