[libvirt] doc: write separate module for hostdev passthrough and in-use tracking
Chunyan Liu
cyliu at suse.com
Thu Apr 18 08:56:02 UTC 2013
2013/4/17 Daniel P. Berrange <berrange at redhat.com>
> On Fri, Mar 22, 2013 at 05:36:09PM +0800, Chunyan Liu wrote:
> > Hi, List,
> >
> > As the mail I've sent a week before:
> > https://www.redhat.com/archives/libvir-list/2013-March/msg00730.html
> > I'm willing to push this work forward so that the passthrough APIs
> > could be reused by qemu driver and libxl driver (which doesn't support
> > pci passthrough yet and tries to add this function recently), or other
> > drivers.
> >
> > But since this work affacts a lot, I'm not sure if I can control it in
> > a correct way. I write a draft to describe what I'm considering how to
> > do, as in the following and in attachment. Hope to get your review,
> > comment and guidence to improve the work before start coding. Any
> > feedback will be very appreciated!
> >
> > Thanks!
> > Chunyan
> >
> > ------------------------
> > DRAFT:
> >
> > Write separate module for hostdev passthrough
> >
> > 1. Purposes:
> >
> > * Move hostdev passthrough APIs from qemu_hostdev.ch to separate
> module so
> > that they could be reused by other hypervisors too
> >
> > * Maintain global in-use state of hostdevs
> >
> >
> > 2. Module design (draft):
> >
> > * New module name: hostdev_driver
> >
> > * New module files: hostdev_driver.ch hostdev_conf.ch
> >
> > * New Definitions:
> >
> > ## [src/driver.h]
> >
> > typedef struct _virHostdevDriver virHostdevDriver;
> >
> > typedef virHostdevDriver *virHostdevDriverPtr;
> >
> > struct _virHosedevDriver {
> > const char *name;
> > virDrvOpen open;
> > virDrvClose close;
> >
> > virDrvPrepareHostdevs prepareHostdevs;
> > virDrvPreparePciHostdevs preparePciHostdevs;
> > virDrvprepareUsbHostdevs prepareUsbHostdevs;
> > virDrvReattachHostdevs reattachHostdevs;
> > virDrvReattachPciHostdevs reattachPciHostdevs;
> > virDrvReattachUsbHostdevs reattachUsbHostdevs;
> > virDrvGetActivePciHostdevList getActivePciHostdevList;
> > virDrvGetActiveUsbHostdevList getActiveUsbHostdevList;
> > virDrvGetDomainActivePciHostdevList
> > getDomainActivePciHostdevList;
> > virDrvGetDomainActiveUsbHostdevList
> > getDomainActiveUsbHostdevList;
> > };
>
> This is real overkill - we only need to do the driver table
> design for things which are public APIs with multiple pluggable
> implementations.
>
> For this scenario, we simply need one single set of internal APIs
> that any of the stateful hypervisor drivers can directly call into.
> Basically you just need to define some object to maintain the
> state eg
>
> virHostdevManagerPtr
>
> and a method to get the default shared instance of it
>
> virHostdevManagerPtr virHostdevManagerGetDefault();
>
> and then the various APIs for interacting with it
>
> virHostdevManagerPrepareHostdevs(virHostdevManagerPtr mgr, ....);
> ...etc..
>
> I'd just put this is all in a src/util/virhostdevmanager.{c,h}
> file.
>
Got it. I'm writing it in the way you pointed, as a shared module instead
of a driver, as Osier has pointed out too. Thanks for your suggestion about
detail, I'll change code to follow that.
> Regards,
> 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:|
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130418/06873b02/attachment-0001.htm>
More information about the libvir-list
mailing list