Il 22/02/2013 10:35, Markus Armbruster ha scritto: > Paolo Bonzini <pbonz...@redhat.com> writes: > >> Il 21/02/2013 15:41, Markus Armbruster ha scritto: >>> Trouble is the user interface is as confusing as ever. Worse, in a way, >>> because we now have to explain how "vlan" and the hubport netdev relate. >>> >>> Permit me a brief rant. Have you read the manual page on -netdev and >>> -net recently? Have you tried to explain setting up QEMU networking to >>> a neophyte? Were you able to keep a straight face? If yes, congrats, >>> you got a great future ahead of you. >>> >>> We have so many ways to do the same thing, complicating our docs >>> enormously. Just one of them makes sense for almost all uses, but I >>> doubt mortal users could guess which one just from the docs. >>> >>> Can we do for the docs what Stefan did for the code, i.e. get "vlans" >>> out of the way? >>> >>> Specifically, what's missing to let us deprecate -net completely? >> >> Less important: the fact that "-net dump" is quite useful and requires >> vlans. > > Let me rephrase: dumping network traffic is quite useful, and our > current way to do that from within QEMU requires "vlans". > > The "dump" vlan client is neither a net frontend nor a net backend, it's > a passive listener. Could also be viewed as special case of a filter > that happens not to change anything. > > If it's the only useful listener or filter, we could just special-case > it and be done. > > If not, we need a way to attach listeners to the 1:1 netdev connections, > or turn it in a chain with filters as interior nodes. > >> ("-net socket" has some usecases too: "-net bridge" helps placing >> a VM's network on a bridge, but adding a bridge still requires root >> privileges). > > "-netdev socket" and "-netdev bridge" don't cut it?
"-netdev bridge" works great. If you want to bridge multiple guest NICs on the same socket, however, you need the VLAN mechanism (though actually you can also use "-netdev socket,mcast" if that works). > To be more precise: -device currently works only for devices on > pluggable buses. > > Anything you could plug on a physical machine should be on a pluggable > bus (whether we implemented plugging is another question). > > Anything you couldn't plug on a physical machine must be soldered onto > the board. Boards often come in a few flavours with different onboard > devices. Virtual boards tend to sprout more flavours. Because of that, > thinking in board options you can combine is often more convenient than > having a finite number of board variants. > > QOM will hopefully enable us to stitch devices together without the need > for buses. Still, you have to tell the board "this is NIC 0", because it is the board logic that knows the MMIO base address of the NICs---not the NIC itself. At least, that's how the authors of embedded ports structure their code (see recent disappearance of sysbus_add_memory; enabling pervasive use of "-device" would instead require sysbus_mmio_map to disappear!). Paolo > So, I quite agree that we need a way to configure board options. Our > current way to do that for NICs is multiplexed into -net as "-net nic". > > "-net nic" is quite unlike the other -net: it doesn't create a vlan > client, it asks the board to create a NIC device. Parameter "model" > lets you ask for a specific one. > > Boards can do what they want with these requests. Some boards don't > support NICs and simply ignore these requests (generic code attempts to > detect that and warn). Others treat models they don't know as fatal > error. Some boards create exactly the NICs you asked for. Others > create exactly their onboard NICs, whether you asked for them or not > (asking is merely a way to supply configuration parameters). > > Most (all?) boards can tell you what models they support (-net > nic,model=help), but some lie, e.g. PCs neglect to mention model > ne2k_isa. > > Boards supporting PCI generally recognize a few common PCI NIC models. > But you're better off using -device there, because it gives you access > to all device models and options at no extra charge. > > "Well, here's another nice mess you've gotten me into, Stanley!" > > > TL;DR: I quite agree that we can't just throw away -net without a > replacement. I just think it's a mess, and should be replaced. >