qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] tun/tap networking: patch for existing tun


From: Jim C. Brown
Subject: Re: [Qemu-devel] tun/tap networking: patch for existing tun
Date: Mon, 3 Oct 2005 11:14:25 -0400
User-agent: Mutt/1.4i

On Mon, Oct 03, 2005 at 02:54:42PM +0200, Henrik Nordstrom wrote:
>
> On Sun, 2 Oct 2005, Jim C. Brown wrote:
> >What it really boils down to is cleaning up the command line options for 
> >the
> >network interface(s), which up to now have been added in a hackish, 
> >piece-wise
> >manner.
> 
> And persistent TUN TAP devices makes it extremely clean on the host, and 
> as it is not difficult for qemu there is not really any reason why not.
> 
> One could obviously drop all the TUN/TAP setup code from qemu, requiring 
> the user to wrap qemu in some application passing it already opened 
> sockets using -tun-fd, but this will be a bit cumbersome to users.. but on 
> the other hand not worse than the users using VDE or similar userspace 
> switches/hubs.

This is definitely the wrong way to go. A separate program shouldn't be 
necessary
for handling what is probably the most common networking mode for qemu. qemu
should support using tap devices (persistent or otherwise) on its own in an
easy-to-understand manner. In fact, I like Fabrice's -net syntax.

An argument for adding vde support in qemu itself does exist - but VDE provides
its own wrapper so thats not really too much hassle for the end user. Also,
VDE may not be popular enough to justify adding vde-specific code to qemu.
(I haven't taken any polls, so I don't know if it is or not. Personally I would
have no objection. BTW, it seems bochs has native support for vde now.)

> 
> >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).
> 
> VDE and a number of other similar applications is a fairly strong reason 
> to support the -tun-fd functionality I would say.
> 

I'd argue that -tun-fd is the wrong name. However, there may be less popular
switches (maybe someone can make qemu run on uml_switch for example) - so the
functionality should stay. Incidently, does the current -tun-fd code work
for windows hosts?

> 
> Regards
> Henrik
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]