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

[Jean-Christian de Rivaz <jc@eclis.ch>]

> 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