Gregory Haskins wrote:
So again, I am proposing for consideration of accepting my work (either
in its current form, or something we agree on after the normal review
process) not only on the basis of the future development of the
platform, but also to keep current components in their running to their
full potential. I will again point out that the code is almost
completely off to the side, can be completely disabled with config
options, and I will maintain it. Therefore the only real impact is to
people who care to even try it, and to me.
Your work is a whole stack. Let's look at the constituents.
- a new virtual bus for enumerating devices.
Sorry, I still don't see the point. It will just make writing drivers
more difficult. The only advantage I've heard from you is that it gets
rid of the gunk. Well, we still have to support the gunk for non-pv
devices so the gunk is basically free. The clean version is expensive
since we need to port it to all guests and implement exciting features
like hotplug.
- finer-grained point-to-point communication abstractions
Where virtio has ring+signalling together, you layer the two. For
networking, it doesn't matter. For other applications, it may be
helpful, perhaps you have something in mind.
- your "bidirectional napi" model for the network device
virtio implements exactly the same thing, except for the case of tx
mitigation, due to my (perhaps pig-headed) rejection of doing things in
a separate thread, and due to the total lack of sane APIs for packet
traffic.
- a kernel implementation of the host networking device
Given the continuous rejection (or rather, their continuous
non-adoption-and-implementation) of my ideas re zerocopy networking aio,
that seems like a pragmatic approach. I wish it were otherwise.
- a promise of more wonderful things yet to come
Obviously I can't evaluate this.
Did I miss anything?
Right now my preferred course of action is to implement a prototype
userspace notification for networking. Second choice is to move the
host virtio implementation into the kernel. I simply don't see how the
rest of the stack is cost effective.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
