Rusty Russell wrote:
On Fri, 2007-07-06 at 14:42 +0200, arnd@xxxxxxxx wrote:
This is a subject that came up in the virtio BOF session
at OLS. I decided to go forward and implement something
that I like, based on the latest virtio proposal at the
time, which was draft III.
It's not a drop-in replacement, because it's missing a
host implementation. I first started my own, which is
not done yet, but wanted to do one for lguest and one
for emulated PCI next. It's also entirely untested.
Hi Arnd,
I think it will come down to how neat PCI<->virtio is. Can we push
further towards PCI without screwing non-PCI? eg. can we use
pci_device_id? struct pci_driver? (Might be pushing it, but should
probably be considered: it'd be neat if some platforms could #define
virtio_driver_register pci_driver_register).
This is liable to cause breakage when something changes. And if I
weren't such a sweet person I'd say it's also horribly ugly.
Standardizing how to pack the info for each device into the config
space would be especially useful. Our drivers are going to get more
featureful, and we're going to need a versioning/compatibility scheme
too.
Basically, I'd like to see someone start with work from the PCI side,
then make sure non-PCI isn't overly burdened.
We can certainly make non-bus specific code, like the feature bitmaps,
shared. I do agree that it makes sense to start from the PCI side as
virtbus doesn't have any constraints.
--
error compiling committee.c: too many arguments to function
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
