From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EMRR5-0004Xg-Oq for qemu-devel@nongnu.org; Mon, 03 Oct 2005 10:36:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EMRR4-0004Wz-U7 for qemu-devel@nongnu.org; Mon, 03 Oct 2005 10:36:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EMROY-0003Jb-Km for qemu-devel@nongnu.org; Mon, 03 Oct 2005 10:34:22 -0400 Received: from [144.85.15.72] (helo=mail.eclis.ch) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EMQq2-0001rM-7O for qemu-devel@nongnu.org; Mon, 03 Oct 2005 09:58:42 -0400 Message-ID: <4341390F.1050107@eclis.ch> Date: Mon, 03 Oct 2005 15:58:39 +0200 From: Jean-Christian de Rivaz MIME-Version: 1.0 Subject: Re: [Qemu-devel] tun/tap networking: patch for existing tun References: <20050930221321.C7BED31C14@ravel.n2.net> <20050930230149.GA20433@jbrown.mylinuxbox.org> <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> In-Reply-To: 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 Henrik Nordstrom a =E9crit : > On Sun, 2 Oct 2005, Jean-Christian de Rivaz wrote: >=20 >> It's already the case with at least my proposed patch. I have't tested= =20 >> the patch written by Henrik Nordstrom or Lars Munch but it's likly=20 >> that there work the same way since this feature come from the Linux=20 >> kernel tun code. >=20 >=20 > Indeed. It is impossible to support persistent TUN/TAP devices without=20 > not also supporting dynamically created devices. Agree. My patch don't drop the dynamic way to use TUN/TAP! Or it has a=20 bug in it. > vde is not the only userspace switch available. Locking qemu to only vd= e=20 > would be bad. I then much prefer not having the builtin vde option or=20 > even the tun/tap open code and only keep -tun-fd. (from -tun-fd all th= e=20 > others can be implemented by a wrapper opening the connections and=20 > handing them over to QEMU) I don't want to stop support of others virtual switch or whatever new=20 interfaces! I just tell about VDE because I like it. Now ok, you can arg=20 that you can make everything with a "-tun-fd" option, but this requier a=20 wrapper for every use and this is I think the best way to confuse users. > See the proposal from Fabrice some month ago on what the command line=20 > parameters should look like. Very nice imho. And very easy to extend=20 > with new modes (VDE, persistent TUN/TAP, whatever) without having to=20 > introduce new confusing options. Ok. --=20 Jean-Christian de Rivaz