Markus Armbruster wrote: > Miguel Di Ciurcio Filho <miguel.fi...@gmail.com> writes: > >> On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka <jan.kis...@web.de> wrote: >>> Miguel Di Ciurcio Filho wrote: >>>> This series removes the vlan stuff without mercy. I've tried to make the >>>> steps >>>> as small as possible, but the last one is huge. I did some basic tests and >>>> networking is still working, so reviews are welcome :-D >>> Sorry, this is a bit too rude. This not only removes the vlan model, >>> something one may talk about, but also the innocent socket back-ends and >>> the useful pcap dump support. >>> >>> Socket back-ends allow quick and easy unprivileged inter-VM network >>> setups. Nothing for production systems, but useful for testing purposes >>> on boxes where taps are not allowed or unhandy to configure. >>> >> I agree that it might be handy sometimes, but one could use VDE for >> that too. Runs on user-space and can be tunneled over SSH or netcat >> [1]. >> Another option would be to make the socket backend properly work as a >> netdev, so one could directly connect guest NICs on different hosts, >> but on a 1:1 relationship. >> >>> The dump client helps to debug user mode guest networks, namely slirp >>> which you did not remove. If that should become the only use case for >>> vlans with more than 2 nodes, we could think about making it a special >>> feature of backend devices. >>> >> socket and dump are only used when the vlan backends are concerned, so >> they don't have any useful meaning outside of that. >> >> How about add dump hooks on backends? I don't think network backends >> need to be stackable like block devices, thought. > > Yes, add a dump hook in net.c for netdev in all the places where a dump > backend on a VLAN gets invoked.
So far dump backends can be hot-added and removed. Once we make them a property of a netdev backend, monitor support to restore this would be good. Something like netdev_dump file=FILE[,len=n], empty filename to disable. > >>> I'm open for cleanups here, but they do require a bit mercy - and should >>> also mention the reason. >>> >> Well, basically there is a lot of "if (vlan) else if (peer)". While >> discussing the query-netdev QMP command, no one has shown any love >> about the vlan stuff at all, quite the contrary and it was kept out of >> the protocol. > > Others are more knowledgable about that than I am, but here's my > understanding. VLANs can't be accelerated. 1:1 connection (netdev) is > almost always just fine. If you need a virtual LAN, there are better > tools to build it than QEMU. That's my understanding as well. But the patch series should state this to make the decision traceable. Jan
signature.asc
Description: OpenPGP digital signature
