You point the real question: why it has been impossible to get accepted
any patch that fixed this. I has proposed one myself and I get no
comment at all. I see similar effort from others and obviousely there
failed almost the same way. No getting any valuable comment about why a
idea proposed by many peopoles is not applyed make this subject very hard.
The change I was talking about is a one line patch...
It's annoying that Fabrice has said nothing about it. But it doesn't actually
mess anything up, it's just confusing for advanced users.
I presume that the device qemu makes is called tun0 because Fabrice wants to
make clear that he doesnt use (and wont support) the ethertap device. Not a
very good reason.
(Or maybe he wants to keep it tun0 because if he changed the name he'd have
to change the option -tun-fd to -tap-fd and that'd break some scripts.)
I hope that we can resolve this subject, because in my point of view,
using a existing "tun" is far more simpler than create one the way quemu
do;
I never mentioned that. At all.
Agree. Sorry, I extented the subjet beyon the initial subjet of this thread.
And qemu already supports that, via the -tun-fd option.
Can you please give me an exemple how to use the -tun-fd option to open
an existing tun (i.e: tun-alice) ? This option only work for already
opened tap/tun interface as I understand.
and this open a lot of new uses in terme of the network managment of
the quemu instance. The very first one for me is to allow only root to
setup a DHCP server and to assign "tuns" interfaces to the users that
needs it, so there don't even have to think about the network setup,
ther just boot into quemu an OS with a DHCP client.
That is a little tricky to do - but qemu can do it.
The problem is exactly because this is tricky! Simply telling quemu to
use a existing tun and boot a OS with a DHCP client is the simplest
operation you can imagine to allow testing network experiment. Network
setup is the job of root. Users just use the setup and that must be dead
simple.
Regards,
--
Jean-Christian de Rivaz
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
