From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ELd31-0007wg-KJ for qemu-devel@nongnu.org; Sat, 01 Oct 2005 04:48:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ELcwB-0007ii-6q for qemu-devel@nongnu.org; Sat, 01 Oct 2005 04:41:47 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ELcu9-0007US-6q for qemu-devel@nongnu.org; Sat, 01 Oct 2005 04:39:39 -0400 Received: from [144.85.15.72] (helo=mail.eclis.ch) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ELcU8-0002kn-Po for qemu-devel@nongnu.org; Sat, 01 Oct 2005 04:12:44 -0400 Message-ID: <433E44F9.8040501@eclis.ch> Date: Sat, 01 Oct 2005 10:12:41 +0200 From: Jean-Christian de Rivaz MIME-Version: 1.0 Subject: Re: [Qemu-devel] tun/tap networking References: <20050930221321.C7BED31C14@ravel.n2.net> <20050930230149.GA20433@jbrown.mylinuxbox.org> In-Reply-To: <20050930230149.GA20433@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 : > Typically, tapX (tap0, tap1, etc) names are reserved for tap devices (e= thernet > frames) and tunX (tun0, tun1, etc) are reserved for tun devices (IP fra= mes). >=20 > 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=20 any patch that fixed this. I has proposed one myself and I get no=20 comment at all. I see similar effort from others and obviousely there=20 failed almost the same way. No getting any valuable comment about why a=20 idea proposed by many peopoles is not applyed make this subject very hard= . I hope that we can resolve this subject, because in my point of view,=20 using a existing "tun" is far more simpler than create one the way quemu=20 do; and this open a lot of new uses in terme of the network managment of=20 the quemu instance. The very first one for me is to allow only root to=20 setup a DHCP server and to assign "tuns" interfaces to the users that=20 needs it, so there don't even have to think about the network setup,=20 ther just boot into quemu an OS with a DHCP client. Any comment this time ? --=20 Jean-Christian de Rivaz