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

[Jim C. Brown]

On Sun, Oct 02, 2005 at 10:23:41PM +0200, Jean-Christian de Rivaz wrote:
> 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.
> 

I'd argue that it should be "-tap" or "-tuntap" instead of "-tun", since using
tun would confuse users who knew the distinction between tun devices and tap
devices.

I'm not sure if a "-vde" option is necessary or a good idea, though. We might
want to keep a "-socket-fd" option around for the really technical people who
do funny things like that. (imho "-tun-fd" is badly named since it doesn't
require a tun/tap fd, it works with any type of file descriptor.)

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

-tun-fd (or -socket-fd) should probably be kept around for really specialized
applications (and the geeks who know how to use them). We should have options
that adaquately cover everything in normal use, of course.

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

Actually, they might just add to the clutter. -dummy-net, -user-net, -nics,
-macaddr, etc. It would be even worse if not for the fact that Fabrice has
refused to incorporate many networking patches (silently, as usual).

So while we're at it, we should redesign the interface for qemu. For each nic,
we'd have -net type[,macaddr] where type is "tap" or "user" or "dummy" and
the macaddr is an (optional) parameter that replaces -macaddr. Number of nics
would depend on number of -net options, with none meaning either no nics or
one nic defaulting to tap (or user if tap isn't available).

For the tap type we could have a 3rd optional parameter for the name, e.g.
-net tap,macaddr,name (with name defaulting to tapX if its not specified).

> -- 
> Jean-Christian de Rivaz
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.