[virt-tools-list] Re: libosinfo - RFC v2

[Arjun Roy]

On 10/26/2009 03:14 PM, Daniel P. Berrange wrote:
> On Mon, Oct 26, 2009 at 09:05:44PM +0000, Daniel P. Berrange wrote:
>> I think we should consider whether we need to represent drivers as more
>> than just strings, and also how we should classify device types. We may
>> need to have multiple types against a device, for example a USB device
>> may be both an audio & video device at the same time. For that matter we
>> probably need to note whether the device is an ISA, PCI or USB device
>> here. If you search the PCI IDs list at http://pci-ids.ucw.cz/ for the
>> device 'ac97' you'll find about 15 matches, so its not all that great
>> as a unique identifier - product/vendor pair is more exact.  Yeah it is
>> suboptimal that libvirt uses the string format.
>>
>> I hate to say it, but do we perhaps need to have a top level  <device>
>> type like ?
>>
>>    <device rdf:about="http://pci-ids.ucw.cz/read/PC/1274/5000">
>>       <short-id>es1371</short-id>
>>       <class type='audio'/>
>>       <bus type='pci' vendor='0x1274' product='x05000'/>
>>    </device>
>
> Actually I'm wrong in suggesting short-id here - it should be a link
> attribute of the relationship between the hypervisor & the device, 
> since it is the hypervisor's name of the device. With that the XML
> would be like
>
>     <device rdf:about="http://pci-ids.ucw.cz/read/PC/1274/5000">
>       <class type='audio'/>
>       <bus type='pci' vendor='0x1274' product='x05000'/>
>     </device>And the short name visible thus:
>
>     <hypervisor rdf:about="http://qemu.org/qemu-kvm-0.11.0">
>       <name>KVM</name>
>       <version>0.11.0</version>
>       <device name="ac97" rdf:resource="http://pci-ids.ucw.cz/read/PC/1002/4382'/>
>       <device name="es1391' rdf:resource="http://pci-ids.ucw.cz/read/PC/1274/5000"/>
>       ....
>     </hypervisor>
>
> This allows the possibilty that 'ac97' refers to different devices for 
> different hypervisors, nicely taking care of the fact that there are a
> great many different devices called 'ac97' and there's no guarentee each
> HV provides the same one.
>
> This may all sound over-complex, but bear in mind that all of the 
> <device> elements can be completely  auto-generated from the master
> PCI ID list, and master USB ID lists published online
>
>   http://pciids.sourceforge.net/
>   http://www.linux-usb.org/usb.ids
>
> Though we'd need to manually write the XML for legacy/ISA devices, there
> are not many of those to worry about.
>

Alright, so instead of just a string representing a device driver, we now have a
top level object representing a device, and a mapping between devices and
hypervisors where a <hypervisor, device> pair specifies a driver?

In that case, I'm guessing we'd need methods for:
- For the hypervisor specified for this instance of the library, get a list of
all osi_device_t supported by the hypervisor that we can iterate through
- For each osi_device_t, enumerate the relevant properties (including multiple
possible values for device class)
- Given a hypervisor, and say, a target OS that we want to run, have it represent
the device driver choices as a list of osi_device_t, where this list is an
intersection of what the hypervisor supports, what the OS supports for the given
hypervisor/other conditions, and what is requested. The device has a drivername
property, the answer for which is dependent on the choice of hypervisor?

One important question though; suppose we have here a top level device object,
and a mapping between hypervisors and devices. What will be the relationship
between distros and devices? Will it be a case of hypervisor has links to
(support for) devices, os has links to (support for) devices, and the returned
result is just an intersection of these two sets?

Regarding how exactly we generate the values for supported devices, at present I
do not care about that.

-Arjun