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

Tue Oct 27 14:12:44 UTC 2009

On Tue, Oct 27, 2009 at 12:13:10AM -0400, Arjun Roy wrote:
> 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?

Yep,

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

3 objects,  device, hypervisor, operating system, and a n<->n link
between device & hypervisor and another between device & OS.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|