From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EMAWm-00073M-Qv for qemu-devel@nongnu.org; Sun, 02 Oct 2005 16:33:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EMAWi-00071D-LJ for qemu-devel@nongnu.org; Sun, 02 Oct 2005 16:33:43 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EMAWi-0006s7-3F for qemu-devel@nongnu.org; Sun, 02 Oct 2005 16:33:40 -0400 Received: from [144.85.15.72] (helo=mail.eclis.ch) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EMAN5-0006qf-RA for qemu-devel@nongnu.org; Sun, 02 Oct 2005 16:23:44 -0400 Message-ID: <434041CD.9080507@eclis.ch> Date: Sun, 02 Oct 2005 22:23:41 +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> In-Reply-To: <20051002193912.GB13825@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 : > On Sun, Oct 02, 2005 at 01:45:16PM -0500, Anthony Liguori wrote: >=20 >>I don't understand, why is this patch needed? >> >=20 >=20 > It makes qemu easier to use. >=20 > A lot easier to use a persistent tap by doing "qemu -use-already-open-t= ap tap1" > instead of hacking around with persistenttapdev.c I am happy to see your comment, realy :-) >>It's a pretty simple C program to create a tun device by whatever name=20 >>you want and just pass the fd to qemu via -tun-fd. I think it's=20 >>generally better to have the least number of options necessary to make=20 >>things easier to understand. >> >=20 >=20 > Like the way vdeq/vdeqemu does it? That works, but is that really the b= est way > to handle it? >=20 > vdeq works the way it does because the odds of getting a special "-vde-= socket" > option in qemu were moot. And perhaps so the author of VDE could have c= ontrol > over what options vdeq supported. (In the case of vdeq, its a clever ha= ck: both > tuntap devices and sockets are controlled via fds, so vdeq sends a sock= et fd > instead of a tuntap fd and qemu is none the wiser. Hypothetically one c= ould > even pass a regular file via -tun-fd.) VDE is a very useful code to complete project like qemu. It requiere=20 special code to connect to the vde_switch, but this not a complexe code=20 (see how vde_plug make that). Since VDE is higly likly used with qemu, I=20 see a good thing that qemu have ditrectly an -vde option and a -tun=20 option. This will corver a large part of real use and still be dead=20 simple to understand for the user. > Having an option for specifying tuntap devices by name on the command l= ine > (persistent or not) is the cleanest way to do it, and also the easiest = for the > user. Maybe even make it so we just pass an option "-tap tap0": if tap0= doesnt > exist then qemu creates a new device with that name, if it does exist t= hen > qemu opens it as if it were a persistent tuntap. 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 that=20 there work the same way since this feature come from the Linux kernel=20 tun code. > In fact, if qemu supported both these things, then I don't see a reason= for > -tun-fd at all (except for something like VDE). Agree, and a -vde option will go forward in this direction. >>Is it really something that so many people would want to use that it=20 >>warrants making it an option? Is there a concrete use-case that this=20 >>enables? >=20 >=20 > What it really boils down to is cleaning up the command line options fo= r the > network interface(s), which up to now have been added in a hackish, pie= ce-wise > manner. So an open question: is the -tun and -vde options a good idea to cleanup=20 the network interface options ? To be clear, I don't propose to remove=20 option at this point, but just to make qemu more easy to use for simple=20 and most common setup. --=20 Jean-Christian de Rivaz