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

[Jean-Christian de Rivaz]

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

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