kvm (and lguest!) want to get more speed out of the tun device.  We already 
have an ABI for guest<->host comms, called virtio_ring; extending tun to 
understand this (with its async nature and batching) make for an efficient 
network.

But moreover: the same things that make virtio a good guest<->host transport 
make it appealing as a userspace<->kernel transport.  So rather than do 
something just for tun, we create a /dev/vring.  We could do a system call, 
but /dev/vring is sufficient.  It is a nice, simple format for normal tun 
usage too.

We do need a small (backwards-compatible) extension to the ring format if 
we're going to do this however, since we didn't previously expose the 
consumer's view of the producer (and vice verse) in the ring because the 
other end doesn't need to see it.  However, it means that a middleman (as the 
kvm or lguest launcher process now becomes) cannot save and restore all the 
ring state.

Cheers,
Rusty.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/