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

On Tue, Mar 13, 2007 at 12:12:56PM -0400, Daniel Veillard 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'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. 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> Anyway, now onto input devices. It would seem like a reasonable idea to have a top level '<input>' device element. 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'/> 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> That's not entirely accurate - we can already do dynamic hotplug add & remove for <disk> devices on paravirt - that Xen cannot currently do it for fully virt is really just an artifact of the particular implementation. If fact if you use paravirt drivers for fully-virt / HVM you *can* do disk & network hotplug. 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. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|