Paolo Bonzini <pbonz...@redhat.com> writes: > 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).
I don't mind keeping "vlans" around for somewhat exotic use cases, now that Stefan restructured the code to get them out of the way. I'm looking for ways to get a similar improvement in the user interface. Right now, qemu(1) mentions "vlan" first, and netdev second, if at all. Additionally, I'm wondering whether we can further reduce "vlan" use cases. >> 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!). To be precise: you tell the board how you want NIC 0 configured. My argument is that "-net nic" is a lousy way to do that. In more detail: >> 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.