On Sun, Oct 02, 2005 at 01:45:16PM -0500, Anthony Liguori wrote: > I don't understand, why is this patch needed? >
It makes qemu easier to use. A lot easier to use a persistent tap by doing "qemu -use-already-open-tap tap1" instead of hacking around with persistenttapdev.c > It's a pretty simple C program to create a tun device by whatever name > you want and just pass the fd to qemu via -tun-fd. I think it's > generally better to have the least number of options necessary to make > things easier to understand. > Like the way vdeq/vdeqemu does it? That works, but is that really the best way to handle it? 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 control over what options vdeq supported. (In the case of vdeq, its a clever hack: both tuntap devices and sockets are controlled via fds, so vdeq sends a socket fd instead of a tuntap fd and qemu is none the wiser. Hypothetically one could even pass a regular file via -tun-fd.) Having an option for specifying tuntap devices by name on the command line (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 then qemu opens it as if it were a persistent tuntap. 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). > Is it really something that so many people would want to use that it > warrants making it an option? Is there a concrete use-case that this > enables? 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. > > Regards, > > Anthony Liguori > > >Maybe can I propose to joint our effort ? > > > > > _______________________________________________ > 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. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel