[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] tun/tap networking: patch for existing tun

From: Henrik Nordstrom
Subject: Re: [Qemu-devel] tun/tap networking: patch for existing tun
Date: Mon, 3 Oct 2005 14:54:42 +0200 (CEST)

On Sun, 2 Oct 2005, Jim C. Brown wrote:

vdeq works the way it does because the odds of getting a special "-vde-socket"
option in qemu were moot. And perhaps so the author of VDE could have control
over what options vdeq supported. (In the case of vdeq, its a clever hack: both
tuntap devices and sockets are controlled via fds, so vdeq sends a socket fd
instead of a tuntap fd and qemu is none the wiser. Hypothetically one could
even pass a regular file via -tun-fd.)

It needs to be a datagram socket, but any kind of datagram socket will do fine.

Having an option for specifying tuntap devices by name on the command line
(persistent or not) is the cleanest way to do it, and also the easiest for the
user. Maybe even make it so we just pass an option "-tap tap0": if tap0 doesnt
exist then qemu creates a new device with that name, if it does exist then
qemu opens it as if it were a persistent tuntap.

And fits extremely nicely in the command line scheme Fabrice proposed some weeks ago.

In fact, if qemu supported both these things, then I don't see a reason for
-tun-fd at all (except for something like VDE).

VDE and a number of other similar applications is a fairly strong reason to support the -tun-fd functionality I would say.

What it really boils down to is cleaning up the command line options for the
network interface(s), which up to now have been added in a hackish, piece-wise

And persistent TUN TAP devices makes it extremely clean on the host, and as it is not difficult for qemu there is not really any reason why not.

One could obviously drop all the TUN/TAP setup code from qemu, requiring the user to wrap qemu in some application passing it already opened sockets using -tun-fd, but this will be a bit cumbersome to users.. but on the other hand not worse than the users using VDE or similar userspace switches/hubs.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]