[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: Jean-Christian de Rivaz
Subject: Re: [Qemu-devel] tun/tap networking: patch for existing tun
Date: Sun, 02 Oct 2005 22:23:41 +0200
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050817)

Jim C. Brown a écrit :
On Sun, Oct 02, 2005 at 01:45:16PM -0500, Anthony Liguori wrote:

I don't understand, why is this patch needed?

It makes qemu easier to use.

A lot easier to use a persistent tap by doing "qemu -use-already-open-tap tap1"
instead of hacking around with persistenttapdev.c

I am happy to see your comment, realy :-)

It's a pretty simple C program to create a tun device by whatever name you want and just pass the fd to qemu via -tun-fd. I think it's generally better to have the least number of options necessary to make things easier to understand.

Like the way vdeq/vdeqemu does it? That works, but is that really the best way
to handle it?

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.)

VDE is a very useful code to complete project like qemu. It requiere special code to connect to the vde_switch, but this not a complexe code (see how vde_plug make that). Since VDE is higly likly used with qemu, I see a good thing that qemu have ditrectly an -vde option and a -tun option. This will corver a large part of real use and still be dead simple to understand for the user.

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.

It's already the case with at least my proposed patch. I have't tested the patch written by Henrik Nordstrom or Lars Munch but it's likly that there work the same way since this feature come from the Linux kernel tun code.

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).

Agree, and a -vde option will go forward in this direction.

Is it really something that so many people would want to use that it warrants making it an option? Is there a concrete use-case that this enables?

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

So an open question: is the -tun and -vde options a good idea to cleanup the network interface options ? To be clear, I don't propose to remove option at this point, but just to make qemu more easy to use for simple and most common setup.

Jean-Christian de Rivaz

reply via email to

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