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

Reply via email to