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

[George Dunlap]

On Tue, Dec 1, 2015 at 12:09 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 
> Acked-by: Juergen Gross 

Committers,

Is there anything else that needs to be done for this to be checked in?

 -George

> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Juergen Gross 
> CC: Chun Yan Liu 
> CC: Olaf Hering 
>
> Changes in v2:
> - Fixed typos
>
> Changes in v1 (since the RFC):
>
> - Use  rather than , and  rather than specifying
>   controller and device.  The idea being to allow SCSI to use
>   terminology more natural to it (i.e., scsihost, scsitarget, scsilun)
>   rather than naming things after USB (controller & device).
>
> - Do not require each  to have a deviceid, but just a unique
>   naming schema.
>
> - Allow multiple levels.
>
> - Include the paragraph about domain configuration lists.
> ---
>  tools/libxl/libxl.h | 65 
> +
>  1 file changed, 65 insertions(+)
>
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 6b73848..44e2951 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1396,6 +1396,71 @@ 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 classes of device,
> + * however, like USB or SCSI, inherently have the need to have a
> + * hierarchy of different levels, with lower-level devices "attached"
> + * to higher-level ones.  USB for instance has "controllers" at the
> + * top, which have buses, on which are devices, which consist of
> + * multiple interfaces.  SCSI has "hosts" at the top, then buses,
> + * targets, and LUNs.
> + *
> + * In that case, for each , there will be a set of functions
> + * and types for each .  For example, for =usb, there
> + * may be  ctrl (controller) and dev (device), with ctrl being
> + * level 0.
> + *
> + * libxl_device__ 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
> + *  libxl_devid namespace.
> + *
> + * Lower-level devices must have a unique way to be identified.  One
> + * way to do this would be to name it via the name of the next level
> + * up plus an index; for instance, .  Another
> + * way would be to have another devid namespace for that level.  This
> + * identifier will be used for queries and removals.
> + *
> + * Lower-level devices will include in their
> + * libxl_device_ struct a field referring to the unique
> + * index of the level above.  For instance, libxl_device_usbdev might
> + * contain the controller devid.
> + *
> + * 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 empty reference to
> + * the level above, it may return an error.  Or it may (but is not
> + * required to) automatically choose a suitable device in the level
> + * above to which to attach the new device at this level.  It may also
> + * (but is not required to) automatically create a new device at the
> + * level above if no suitable devices exist.  Each class should
> + * document its behavior.
> + *
> + * libxl_device__list will list all devices of 
> + * at  in the domain.  For example, libxl_device_usbctrl_list
> + * will list all usb controllers; libxl_class_usbdev_list will list
> + * all usb devices across all controllers.
> + *
> + * For each class, the domain config file will contain a single list
> + * for each level.  libxl will first iterate through the list of
> + * top-level devices, then iterate through each level down in turn,
> + * adding devices to devices in the level above.  For instance, there
> + * will be one list for all usb controllers, and one list for all usb
> + * devices.
> + *
> + * If libxl_device__add automatically creates
> + * higher-level devices as necessary, then it is permissible for the
> + * higher-level lists to be empty and the device list to have devices
> + * with the field containing a reference to the higher level device
> + * uninitialized.
>   */
>
>  /* Disks 

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

[Ian Campbell]

On Tue, 2015-12-08 at 12:26 +, George Dunlap wrote:
> On Tue, Dec 1, 2015 at 12:09 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 
> > Acked-by: Juergen Gross 
> 
> Committers,
> 
> Is there anything else that needs to be done for this to be checked in?

Just to prod a committer, sorry for the delay.

Now acked on the basis of Jurgen, Chun Yan and Olaf's Acks and pushed.

Chun Yan, I turned your informal Ack into 
Acked-by: Chun Yan Liu 
I hope that's ok. In future it would be appreciated if you would spell it
out in full to avoid any possible ambiguity or misunderstanding.

Thanks,
Ian.



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Olaf Hering]

On Tue, Dec 01, 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.

Will likely work for pvscsi. Thanks.

Acked-by: Olaf Hering 

Olaf

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[George Dunlap]

On Tue, Dec 1, 2015 at 3:58 PM, Wei Liu  wrote:
> On Tue, Dec 01, 2015 at 12:09:58PM +, George Dunlap wrote:
> [...]
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> index 6b73848..44e2951 100644
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -1396,6 +1396,71 @@ 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 classes of device,
>> + * however, like USB or SCSI, inherently have the need to have a
>> + * hierarchy of different levels, with lower-level devices "attached"
>> + * to higher-level ones.  USB for instance has "controllers" at the
>> + * top, which have buses, on which are devices, which consist of
>> + * multiple interfaces.  SCSI has "hosts" at the top, then buses,
>> + * targets, and LUNs.
>> + *
>> + * In that case, for each , there will be a set of functions
>> + * and types for each .  For example, for =usb, there
>> + * may be  ctrl (controller) and dev (device), with ctrl being
>> + * level 0.
>> + *
>> + * libxl_device__ will act more or
>
> Missed "level0" comment from Chunyan?

The only comment of Chunyan's I could find that has  in it is
actually correcting  => .  Did I
misunderstand, or did you? :-)

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Wei Liu]

On Tue, Dec 01, 2015 at 05:03:28PM +, George Dunlap wrote:
> On Tue, Dec 1, 2015 at 3:58 PM, Wei Liu  wrote:
> > On Tue, Dec 01, 2015 at 12:09:58PM +, George Dunlap wrote:
> > [...]
> >> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> >> index 6b73848..44e2951 100644
> >> --- a/tools/libxl/libxl.h
> >> +++ b/tools/libxl/libxl.h
> >> @@ -1396,6 +1396,71 @@ 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 classes of device,
> >> + * however, like USB or SCSI, inherently have the need to have a
> >> + * hierarchy of different levels, with lower-level devices "attached"
> >> + * to higher-level ones.  USB for instance has "controllers" at the
> >> + * top, which have buses, on which are devices, which consist of
> >> + * multiple interfaces.  SCSI has "hosts" at the top, then buses,
> >> + * targets, and LUNs.
> >> + *
> >> + * In that case, for each , there will be a set of functions
> >> + * and types for each .  For example, for =usb, there
> >> + * may be  ctrl (controller) and dev (device), with ctrl being
> >> + * level 0.
> >> + *
> >> + * libxl_device__ will act more or
> >
> > Missed "level0" comment from Chunyan?
> 
> The only comment of Chunyan's I could find that has  in it is
> actually correcting  => .  Did I
> misunderstand, or did you? :-)

Oops. I misread. Sorry about the noise.

Wei.

> 
>  -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Chun Yan Liu]

>>> On 12/1/2015 at 08:09 PM, in message
<1448971798-3498-1-git-send-email-george.dun...@eu.citrix.com>, 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. 

Acked.

>  
> Signed-off-by: George Dunlap  
> Acked-by: Juergen Gross  
> --- 
> CC: Ian Campbell  
> CC: Ian Jackson  
> CC: Wei Liu  
> CC: Juergen Gross  
> CC: Chun Yan Liu  
> CC: Olaf Hering  
>  
> Changes in v2: 
> - Fixed typos 
>  
> Changes in v1 (since the RFC): 
>  
> - Use  rather than , and  rather than specifying 
>   controller and device.  The idea being to allow SCSI to use 
>   terminology more natural to it (i.e., scsihost, scsitarget, scsilun) 
>   rather than naming things after USB (controller & device). 
>  
> - Do not require each  to have a deviceid, but just a unique 
>   naming schema. 
>  
> - Allow multiple levels. 
>  
> - Include the paragraph about domain configuration lists. 
> --- 
>  tools/libxl/libxl.h | 65  
> + 
>  1 file changed, 65 insertions(+) 
>  
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h 
> index 6b73848..44e2951 100644 
> --- a/tools/libxl/libxl.h 
> +++ b/tools/libxl/libxl.h 
> @@ -1396,6 +1396,71 @@ 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 classes of device, 
> + * however, like USB or SCSI, inherently have the need to have a 
> + * hierarchy of different levels, with lower-level devices "attached" 
> + * to higher-level ones.  USB for instance has "controllers" at the 
> + * top, which have buses, on which are devices, which consist of 
> + * multiple interfaces.  SCSI has "hosts" at the top, then buses, 
> + * targets, and LUNs. 
> + * 
> + * In that case, for each , there will be a set of functions 
> + * and types for each .  For example, for =usb, there 
> + * may be  ctrl (controller) and dev (device), with ctrl being 
> + * level 0. 
> + * 
> + * libxl_device__ 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 
> + *  libxl_devid namespace. 
> + * 
> + * Lower-level devices must have a unique way to be identified.  One 
> + * way to do this would be to name it via the name of the next level 
> + * up plus an index; for instance, .  Another 
> + * way would be to have another devid namespace for that level.  This 
> + * identifier will be used for queries and removals. 
> + * 
> + * Lower-level devices will include in their 
> + * libxl_device_ struct a field referring to the unique 
> + * index of the level above.  For instance, libxl_device_usbdev might 
> + * contain the controller devid. 
> + * 
> + * 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 empty reference to 
> + * the level above, it may return an error.  Or it may (but is not 
> + * required to) automatically choose a suitable device in the level 
> + * above to which to attach the new device at this level.  It may also 
> + * (but is not required to) automatically create a new device at the 
> + * level above if no suitable devices exist.  Each class should 
> + * document its behavior. 
> + * 
> + * libxl_device__list will list all devices of  
> + * at  in the domain.  For example, libxl_device_usbctrl_list 
> + * will list all usb controllers; libxl_class_usbdev_list will list 
> + * all usb devices across all controllers. 
> + * 
> + * For each class, the domain config file will contain a single list 
> + * for each level.  libxl will first iterate through the list of 
> + * top-level devices, then iterate through each level down in turn, 
> + * adding devices to devices in the level above.  For instance, there 
> + * will be one list for all usb controllers, and one list for all usb 
> + * devices. 
> + *  
> + * If libxl_device__add automatically creates 
> + * higher-level devices as necessary, then it is permissible for the 
> + * higher-level lists to be empty and the device list to have devices 
> + * 

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

[Wei Liu]

On Tue, Dec 01, 2015 at 12:09:58PM +, George Dunlap wrote:
[...]
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 6b73848..44e2951 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1396,6 +1396,71 @@ 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 classes of device,
> + * however, like USB or SCSI, inherently have the need to have a
> + * hierarchy of different levels, with lower-level devices "attached"
> + * to higher-level ones.  USB for instance has "controllers" at the
> + * top, which have buses, on which are devices, which consist of
> + * multiple interfaces.  SCSI has "hosts" at the top, then buses,
> + * targets, and LUNs.
> + *
> + * In that case, for each , there will be a set of functions
> + * and types for each .  For example, for =usb, there
> + * may be  ctrl (controller) and dev (device), with ctrl being
> + * level 0.
> + *
> + * libxl_device__ will act more or

Missed "level0" comment from Chunyan?

> + * less like top-level non-bus devices: they will either create or
> + * accept a libxl_devid which will be unique within the
> + *  libxl_devid namespace.
> + *

Ditto.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] libxl: Introduce a template for devices with a controller

[George Dunlap]

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 
Acked-by: Juergen Gross 
---
CC: Ian Campbell 
CC: Ian Jackson 
CC: Wei Liu 
CC: Juergen Gross 
CC: Chun Yan Liu 
CC: Olaf Hering 

Changes in v2:
- Fixed typos

Changes in v1 (since the RFC):

- Use  rather than , and  rather than specifying
  controller and device.  The idea being to allow SCSI to use
  terminology more natural to it (i.e., scsihost, scsitarget, scsilun)
  rather than naming things after USB (controller & device).

- Do not require each  to have a deviceid, but just a unique
  naming schema.

- Allow multiple levels.

- Include the paragraph about domain configuration lists.
---
 tools/libxl/libxl.h | 65 +
 1 file changed, 65 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 6b73848..44e2951 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1396,6 +1396,71 @@ 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 classes of device,
+ * however, like USB or SCSI, inherently have the need to have a
+ * hierarchy of different levels, with lower-level devices "attached"
+ * to higher-level ones.  USB for instance has "controllers" at the
+ * top, which have buses, on which are devices, which consist of
+ * multiple interfaces.  SCSI has "hosts" at the top, then buses,
+ * targets, and LUNs.
+ *
+ * In that case, for each , there will be a set of functions
+ * and types for each .  For example, for =usb, there
+ * may be  ctrl (controller) and dev (device), with ctrl being
+ * level 0.
+ *
+ * libxl_device__ 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
+ *  libxl_devid namespace.
+ *
+ * Lower-level devices must have a unique way to be identified.  One
+ * way to do this would be to name it via the name of the next level
+ * up plus an index; for instance, .  Another
+ * way would be to have another devid namespace for that level.  This
+ * identifier will be used for queries and removals.
+ *
+ * Lower-level devices will include in their
+ * libxl_device_ struct a field referring to the unique
+ * index of the level above.  For instance, libxl_device_usbdev might
+ * contain the controller devid.
+ *
+ * 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 empty reference to
+ * the level above, it may return an error.  Or it may (but is not
+ * required to) automatically choose a suitable device in the level
+ * above to which to attach the new device at this level.  It may also
+ * (but is not required to) automatically create a new device at the
+ * level above if no suitable devices exist.  Each class should
+ * document its behavior.
+ *
+ * libxl_device__list will list all devices of 
+ * at  in the domain.  For example, libxl_device_usbctrl_list
+ * will list all usb controllers; libxl_class_usbdev_list will list
+ * all usb devices across all controllers.
+ *
+ * For each class, the domain config file will contain a single list
+ * for each level.  libxl will first iterate through the list of
+ * top-level devices, then iterate through each level down in turn,
+ * adding devices to devices in the level above.  For instance, there
+ * will be one list for all usb controllers, and one list for all usb
+ * devices.
+ * 
+ * If libxl_device__add automatically creates
+ * higher-level devices as necessary, then it is permissible for the
+ * higher-level lists to be empty and the device list to have devices
+ * with the field containing a reference to the higher level device
+ * uninitialized.
  */
 
 /* Disks */
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel