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.
As things evolved, draft IV is completely different, and
these patches don't make sense any more on them, because
there is no longer the concept of a virtio_device, but
instead there are devices that have an arbitrary number
of virtqueue structures.
I'd still like to discuss my approach to see if there is
reason to continue down that road, so I'm posting what
I have right now.
I think among the options we have to go on are:
1. screw the virtio_bus, and let every host do its own
stuff -- no autoloading, standalone drivers, chardev
host etc.
That's a bit against the spirit of virtio. I think that the control
path will become quite large over time, so it makes sense to share as
much as possible.
2. get virtio_device back from the dead, and allow it
to have multiple virtqueues, either two or an unlimited
number.
This is the best option IMO.
3. screw the multiple-virtqueue idea, go back to the
draft III stuff with my changes.
I'm sure Rusty will just love this one.
4. Delegate the responsibility for extracting the queues to
hypervisor-specific code, but keep the rest shared.
Just for completeness; option 2 is better.
--
error compiling committee.c: too many arguments to function
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
