From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ELhV3-00073k-BN for qemu-devel@nongnu.org; Sat, 01 Oct 2005 09:34:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ELhUs-0006xg-Hz for qemu-devel@nongnu.org; Sat, 01 Oct 2005 09:33:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ELhUq-0006rP-LZ for qemu-devel@nongnu.org; Sat, 01 Oct 2005 09:33:48 -0400 Received: from [128.8.10.163] (helo=po1.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ELhA5-0002aD-Ih for qemu-devel@nongnu.org; Sat, 01 Oct 2005 09:12:21 -0400 Received: from jbrown.mylinuxbox.org (jma-box.student.umd.edu [129.2.253.219]) by po1.wam.umd.edu (8.12.10/8.12.10) with ESMTP id j91DCJrs004487 for ; Sat, 1 Oct 2005 09:12:19 -0400 (EDT) Date: Sat, 1 Oct 2005 09:12:15 -0400 From: "Jim C. Brown" Subject: Re: [Qemu-devel] tun/tap networking Message-ID: <20051001131215.GB28444@jbrown.mylinuxbox.org> References: <20050930221321.C7BED31C14@ravel.n2.net> <20050930230149.GA20433@jbrown.mylinuxbox.org> <433E44F9.8040501@eclis.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433E44F9.8040501@eclis.ch> 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 On Sat, Oct 01, 2005 at 10:12:41AM +0200, Jean-Christian de Rivaz wrote: > Jim C. Brown a ?crit : > > >Typically, tapX (tap0, tap1, etc) names are reserved for tap devices > >(ethernet > >frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP > >frames). > > > >qemu breaks those rules and calls the tap device that it creates tun0. > >This is > >done for reasons that Fabrice has not made clear. (I assume there is a > >reason > >for it because he has refused to apply any of the patches that fix this.) > > You point the real question: why it has been impossible to get accepted > any patch that fixed this. I has proposed one myself and I get no > comment at all. I see similar effort from others and obviousely there > failed almost the same way. No getting any valuable comment about why a > idea proposed by many peopoles is not applyed make this subject very hard. > The change I was talking about is a one line patch... It's annoying that Fabrice has said nothing about it. But it doesn't actually mess anything up, it's just confusing for advanced users. I presume that the device qemu makes is called tun0 because Fabrice wants to make clear that he doesnt use (and wont support) the ethertap device. Not a very good reason. (Or maybe he wants to keep it tun0 because if he changed the name he'd have to change the option -tun-fd to -tap-fd and that'd break some scripts.) > I hope that we can resolve this subject, because in my point of view, > using a existing "tun" is far more simpler than create one the way quemu > do; I never mentioned that. At all. And qemu already supports that, via the -tun-fd option. > and this open a lot of new uses in terme of the network managment of > the quemu instance. The very first one for me is to allow only root to > setup a DHCP server and to assign "tuns" interfaces to the users that > needs it, so there don't even have to think about the network setup, > ther just boot into quemu an OS with a DHCP client. > That is a little tricky to do - but qemu can do it. > Any comment this time ? > -- > Jean-Christian de Rivaz > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.