[Libvir] [PATCH] Enable USB device setting information handling on virsh.

Daniel Veillard veillard at redhat.com
Wed Mar 14 15:54:41 UTC 2007

On Wed, Mar 14, 2007 at 03:38:02AM +0000, Daniel P. Berrange wrote:
> I'm not so sure about this to be honest. This is very verbose syntax and having
> the empty <usb> wrapper around every element isn't adding all that much useful
> info in relation to its verbosity.

  I based my review on the structure, this was looking flexible enough to
not raise big problem, but I didn't tried to make a global analysis, thanks
for doing this !

> I've been thinking about how the contents of the <devices> section relates to
> the way Linux models devices in sysfs. Thus far we have 'interface', 'disk'
> 'console' and 'graphics'. 
>   - The 'disk' element maps onto /sys/block or /sys/class/scsi_disk
>   - The 'interface' element maps onto /sys/class/net
>   - The 'graphics' element maps onto /sys/class/graphics
>   - The 'console' element maps onto /sys/class/misc
> I tend to think of /sys/block as really being a class too (ie /sys/class/block).
> With the way we've been thinking about USB in this thread so far though, we're
> approaching a model that is much more like /sys/bus rather than /sys/class. ie
> we're grouping everything under a bus type at the top level, rather than the
> rest of the nodes which are grouped by class (function).
> Listing again at what things we need to represent here:
>   - Input devices - mouse, tablet
>   - Disk devices
>   - Presence of USB or not (aka whether a bus is emulated)
>   - Pass through of devices from the host bus
> Now consider a couple of non-USB related things we don't have representations
> for yet
>   - VMWare mouse type
>   - Summa graphics tablet - a serial device tablet
>   - PS/2  mouse - implicitly represented if we don't ask for any other mouse
>   - PCI device pass through from host
>   - Serial ports
>   - Parallel ports
>   - Sound cards
> Basically we end up with two sorts of things we need to represent:
>   - Emulation of particular classes of devices grouped by their function
>   - Pass through of real hardware, irrespective of function
> Based on this observation I think we need to actually treat the Xen USB configs in
> two different ways according to the above split. 

  yes that look nicer in the long term

> So USB disks might look like
>    <disk type='file' device='disk'>
>      <source file='/some/path.img'/>
>      <target dev='usb'/>
>    </disk>
> NB, I'm using a generic 'usb' tag as the guest device name, since USB devices are
> fundamentally hotplug oriented it is very unsual to have persistent USB bus IDs
> and thus you'll never have a persistent device node. Maybe its better to have a
> separate named attribute instead of re-using the 'dev' attribute in <target>:
>    <disk type='file' device='disk'>
>      <source file='/some/path.img'/>
>      <target bus='usb'/>
>    </disk>
> Or a separate bus type ?
>    <disk type='file' device='disk'>
>      <source file='/some/path.img'/>
>      <bus type='usb'/>
>    </disk>

  I'm not sure this really adds much over <target dev='usb'/>, we can still
add extra attributes if needed onto target in the usb case.

> Anyway, now onto input devices. It would seem like a reasonable idea to have a
> top level '<input>' device element.

  Yes, but when you mean top level you really mean as child of <devices>, I
see why an input would be any different, right ?

> So a generic USB mouse could be
>     <input type='usbmouse'/>
> While a tablet would be
>     <input type='usbtablet'/>
> Alternatively we could be explicit about the particular type of device / named
> model being emulated, eg for the USB tablet:
>     <input type='evtouch'/>
> The downside with the latter is that its probably different device name for
> every different virt system. If we just kept a generic 'usbmouse' it would
> represent 'whatever particular usb mouse the virt system supports'.
> My final thought is that we could have 'typoe' be compulsory representing the
> type of pointer. And then 'bus' and 'model' could be optional atttributes to
> give more specific info if needed, eg for tablets these are equivalent:
>     <input type='tablet'/>
>     <input bus='serial' type='tablet'/>
>     <input bus='serial' type='tablet' model='summagraphics'/>
>     <input type='tablet' model='summagraphics'/>
> And these are equivalent:
>     <input type='tablet' model='evtouch'/>
>     <input bus='usb' type='tablet'/>
>     <input bus='usb' type='tablet' model='evtouch'/>

  looks good to me

> When creating a domain, the caller could leave out 'bus' or 'model' if they
> don't care about specific details. When asking libvirt for an XML dump of
> a running domain though, we'd fill in the most specific info we have.
> Finally, for the mapping of host devices through to the guest. In this case we
> probably do just want to group stuff under either a bus specific node, eg
>    <usb>
>      <host vendor='0234' model='2342'/>
>      <host vendor='1248' model='4228'/>
>      <host bus='03' device='02'/>
>    </usb>
>    <pci>
>      <host id='0000:00:1f.1'/>
>    </pci>
> Or a generic bus node
>     <bus type='usb'>
>        <host vendor='0234' model='2342'/>
>        <host vendor='1248' model='4228'/>
>        <host bus='03' device='02'/>
>     </bus>
>     <bus type='pci'>
>        <host id='0000:00:1f.1'/>
>     </bus>

   I prefer the later, it's a bit more structured.

> This email was *significantly* longer than I thought it would be. I guess
> that's good because it shows there's some non-trivial decisions we should
> make before committing to a particular style of implementation. I want to
> ask do a little research of the way USB / PCI devices are expressed with
> VMWare config files, and with the XenAPI  XML-RPC format in case there's
> any useful stuff we can learn from the way they model devices.

  yes thanks for getting deeper on this !


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

More information about the libvir-list mailing list