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 ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/