qemu-devel
[Top][All Lists]
Advanced

[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: Mon, 03 Oct 2005 11:46:57 +0200
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050817)


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.

Ok for "-tuntap" long option. Can I propose "-t" for a short option ?

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

So "-tun-fd" will be renamed "-socket-fd".

The idea of the "-vde" option is to have in parameter the VDE socket (default to "/tmp/vde.ctl") an act like vde_plug so it don't need any other code to work. Just start a "vde_switch" and as many "qemu -vde" you wants to create a complete virtual nework (1 switch and n hosts).

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

Yes, this is the good way to make it, I agree.

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

The fact that we don't know what Fabrice think about this subjet is a problem. Only Fabrice can commit to the qemu CVS as I understand. I hope Fabrice read this list and can provids to us usefull informations on how to make the patch to get it accepted.

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

This is an other work, but why not ?

I think that a syntax like "-net type[:macaddr][,arg[,arg[...]]]" is more usefull, since the MAC addresse of the TAP devices is not alway specified as it can be set randomly by the Linux kernel (with possible collision see code in include/linux/etherdevice.h).

The advantage of your proposition is that it make more easy to add new type of network device like VDE. This enable to possibility to use a "socket-fd" type to make everyone happy.

In case of this new interface, will network script still needed. If yes, how should we handle them in the new option syntax ?

--
Jean-Christian de Rivaz




reply via email to

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