On Tue, Jun 05, 2012 at 09:54:49AM +0200, Christophe Fergeau wrote: > On Mon, Jun 04, 2012 at 08:38:14PM +0300, Zeeshan Ali (Khattak) wrote: > > > As I understand it, sound was not working in Windows 7 because the list of > > > audio devices contained 2 elements, ich6 and ac97. Boxes arbitrarily picked > > > the first element in the list which is ac97, but this one is not working. > > > With your change, the list order is changed and ich6 is first. Since it's > > > the more specific device (it's specified on the 'win7' node in > > > windows.xml), this ordering makes sense even though it's not specified > > > anywehere I could find in the documentation. > > > > > > However, the bigger question (if the above explanation is what you were > > > seeing) is why was a non-working audio device present in the device list > > > returned by libosinfo? > > > > Good point! I don't know how to fix this in a non-intrusive and nice > > way as win7 does inherit from vista and vista from NT. This actually > > brings us to a more generic problem: How do we deal with device > > support being dropped in a later version of the OS? Perhaps we could > > introduce a new node/API for this: > > > > <dropped-devices> > > <device id="http://pciids.sourceforge.net/v2.2/pci.ids/8086/2415"/> > > <!-- AC97 --> > > </dropped-devices> > > > I'm wondering if devices should be inherited at all? There are no > guarantees that from one Windows version to the next, older hardware > support won't get dropped. Currently Windows 7 inherits all the way back to > win95 and picks its supported devices from there, we are lucky that there > are few dropped devices in the mean time ;) The intent of the inheritance was to avoid the need to duplicate information across multiple XML files. While it has some limited benefit, I'm still not 100% convinced this working well in all cases. The example given above is a nice case in point. We may well be better off just maintaining device lists separatly per OS. Or perhaps the <devices> element can gain a inherit="yes|no" attribute, to allow us to turn off inheritance in the (hopefully small number of) cases where a new OS drops support for old hardware. > Something that may work is to decide that a given OS can only have one > device for a given PROP_CLASS, but I'm not sure how realistic of an > assumptoin this is. I don't want us to have that assumption, at least not in this part of the XML. The <os> element should list *all* possible devices that the OS supports, not least because we might need to list different devices, for different hypervisors. Also in theory for Linux we could even auto-generate this by extracting the PCI IDs from running 'modinfo' across every kernel module. WIth the list of devices from <os>, we calculate the intersection against the devices from <platform> (aka hypervisor). Even now though we might still have multiple devices per class. This is what I refer to as the "supported devices" for an (os,hv) pair. We do have a separate entity <deployment> that we have not yet made any use of. The intent of the deployment object is that it is a hard link between a specific OS and a specific hypervisor. Here again we can list devices, and here we *would* restrict it to one per class. This is what I refer to as the "optimal devices", and would be a sub-set of the "supported devices". For mgmt apps I would see the following precedence 1. If there is a <deployment> available for the (os,hv) pair, use the devices from that as the default 2. Find the intersection between <os> and <platform> devices for the (os,hv) pair, and use the first device in the list by default 3. (Optionally) allow the user to request any other device in the list. > Another issue I can see with the current scheme is that it assumes all arch > will use the same devices. While this is reasonably true for x86/x86_64, > this will probably need to be improved if we are ever to support ARM > distros. An additional attribute on the <device> node would probably do the > trick. Indeed, we've not really considered that at all. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
