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

[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 */
> --
> 2.1.4
>
>
> ___
> 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

[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 
> + * with the field containing a reference to the higher level device 
> + * uninitialized. 
>   */ 
>   
>  /* Disks */ 
 


___
Xen-devel mailing list

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

[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 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