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

Jim C. Brown a écrit :

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

One potential issue is that the vde code is under the GPL, while qemu (at
least the part that we're talking about) is under the BSD license.

Ok. that a point to look at. The methode used to connect to a VDE is simple, and it should be relatively a small work to rewrite a new code that do that under the BSD license.

I'm not sure if use of VDE is common enough to justify having special code for
it in qemu anyways.

It's matter to make the use of VDE easy for the users. I think it will become more common that some others options for advancer users. Product like vmware offert a private network setting in standard.

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 macaddr sets the mac address of the guest nic that qemu provides. I do
not know if it is possible to set a tap device's mac address on creation
but if it is possible then I agree that it would be a useful parameter.

From Linux drivers/net/tun.c

static int tun_chr_ioctl(struct inode *inode, struct file *file,
                         unsigned int cmd, unsigned long arg)
        case SIOCSIFHWADDR:
/** Set the character device's hardware address. This is used when * filtering packets being sent from the network device to the character
                 * device. */
                memcpy(tun->dev_addr, ifr.ifr_hwaddr.sa_data,
min(sizeof ifr.ifr_hwaddr.sa_data, sizeof tun->dev_addr)); DBG(KERN_DEBUG "%s: set hardware address: %x:%x:%x:%x:%x:%x\n",
tun->dev_addr[0], tun->dev_addr[1], tun->dev_addr[2], tun->dev_addr[3], tun->dev_addr[4], tun->dev_addr[5]);
                return 0;

Giving this code, I think the answare is yes: it's possible to set the MAC addresse of a TUN/TAP device.

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

Network scripts will only be needed for tuntap devices that are created by
qemu, same as now. The "-n script" thing (defaulting to /etc/qemu-ifup) should
continue to work fine.

The parameters that we choose to pass to the script will be a separate issue.
My vote is qemu-ifup tapname macaddr (with macaddr being what was specified
on the -net command line or the appropriate default).


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.

Actually a lot of the issues have been discussed before. The -net syntax was
his idea I believe. Once Fabrice makes his opinion known, he generally will
keep quiet until code appears.

Once the patch is written, then we can start asking Fabrice for changes or
improvements needed to make the patch commitable (as then we'll actually have
something substantial for him to look at).

Ok. I havn't read all the posts into this maling list, but I hope the indications you provids are the conclusion of what has been discussed before.

Jean-Christian de Rivaz

reply via email to

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