From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EMQBU-00012l-Fv for qemu-devel@nongnu.org; Mon, 03 Oct 2005 09:16:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EMQBH-0000tM-A6 for qemu-devel@nongnu.org; Mon, 03 Oct 2005 09:16:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EMQBD-0000o6-84 for qemu-devel@nongnu.org; Mon, 03 Oct 2005 09:16:31 -0400 Received: from [144.85.15.72] (helo=mail.eclis.ch) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EMQ53-0005q7-SL for qemu-devel@nongnu.org; Mon, 03 Oct 2005 09:10:10 -0400 Message-ID: <43412DAB.9040202@eclis.ch> Date: Mon, 03 Oct 2005 15:10:03 +0200 From: Jean-Christian de Rivaz MIME-Version: 1.0 Subject: Re: [Qemu-devel] tun/tap networking: patch for existing tun References: <433E44F9.8040501@eclis.ch> <20051001131215.GB28444@jbrown.mylinuxbox.org> <433EF5C4.2030801@eclis.ch> <433F92CB.1060600@eclis.ch> <43402ABC.3040805@us.ibm.com> <20051002193912.GB13825@jbrown.mylinuxbox.org> <434041CD.9080507@eclis.ch> <20051002223734.GA17623@jbrown.mylinuxbox.org> <4340FE11.7020403@eclis.ch> <20051003120416.GA25643@jbrown.mylinuxbox.org> In-Reply-To: <20051003120416.GA25643@jbrown.mylinuxbox.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Jim C. Brown a =E9crit : >>The idea of the "-vde" option is to have in parameter the VDE socket=20 >>(default to "/tmp/vde.ctl") an act like vde_plug so it don't need any=20 >>other code to work. Just start a "vde_switch" and as many "qemu -vde"=20 >>you wants to create a complete virtual nework (1 switch and n hosts). >=20 > 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=20 simple, and it should be relatively a small work to rewrite a new code=20 that do that under the BSD license. > I'm not sure if use of VDE is common enough to justify having special c= ode for > it in qemu anyways. It's matter to make the use of VDE easy for the users. I think it will=20 become more common that some others options for advancer users. Product=20 like vmware offert a private network setting in standard. >>I think that a syntax like "-net type[:macaddr][,arg[,arg[...]]]" is=20 >>more usefull, since the MAC addresse of the TAP devices is not alway=20 >>specified as it can be set randomly by the Linux kernel (with possible=20 >>collision see code in include/linux/etherdevice.h). >=20 > 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 creatio= n > 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=20 is used when * filtering packets being sent from the network device=20 to the character * device. */ memcpy(tun->dev_addr, ifr.ifr_hwaddr.sa_data, min(sizeof ifr.ifr_hwaddr.sa_data,=20 sizeof tun->dev_addr)); DBG(KERN_DEBUG "%s: set hardware address:=20 %x:%x:%x:%x:%x:%x\n", tun->dev->name, tun->dev_addr[0], tun->dev_addr[1],=20 tun->dev_addr[2], tun->dev_addr[3], tun->dev_addr[4],=20 tun->dev_addr[5]); return 0; Giving this code, I think the answare is yes: it's possible to set the=20 MAC addresse of a TUN/TAP device. >>In case of this new interface, will network script still needed. If yes= ,=20 >>how should we handle them in the new option syntax ? >=20 > 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. >=20 > 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 speci= fied > on the -net command line or the appropriate default). Ok. >>The fact that we don't know what Fabrice think about this subjet is a=20 >>problem. Only Fabrice can commit to the qemu CVS as I understand. I hop= e=20 >>Fabrice read this list and can provids to us usefull informations on ho= w=20 >>to make the patch to get it accepted. > > Actually a lot of the issues have been discussed before. The -net synta= x was > his idea I believe. Once Fabrice makes his opinion known, he generally = will > keep quiet until code appears. >=20 > 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 actuall= y have > something substantial for him to look at). Ok. I havn't read all the posts into this maling list, but I hope the=20 indications you provids are the conclusion of what has been discussed=20 before. --=20 Jean-Christian de Rivaz