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 netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html