[virt-tools-list] [libosinfo] Fix osinfo_list_add_union()

[Daniel P. Berrange]

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