On 5 May 2013 22:15, Michael S. Tsirkin <m...@redhat.com> wrote: > On Sun, May 05, 2013 at 07:01:34PM +0100, Peter Maydell wrote: >> Sorry, you can't say this until we've sorted out the mess >> that is new-style networking options in a machine which >> creates embedded network controllers.
> What is missing exactly? > Could you please give some examples of the problems > that -netdev + -device has but -net does not have? -netdev + -device is fine (unsurprisingly since that's the PC usecase); -netdev + a device that's preinstantiated by the board is not so fine. And you can't use -device to instantiate most embedded network controllers because there's no way to wire up the IRQs and MMIOs. There's probably a nasty workaround involving '-global', but: * that requires the user to know the device name for the onboard NIC for the board, which is a regression from the -net situation * it's not clear how it works if the board has two NICs of the same type * if we claim -global is the right approach we need to actually document it (and document all the board NIC names, yuck) * we need to fix existing boards which do the "don't instantiate NIC unless the user said -net nic" trick by looking at nd_table[] * we need to make the board code pass the right NIC properties in both the "legacy -net option" and "new style" cases (at the moment, for instance, lan911_init() insists on having a NICInfo* passed to it) -net nic works for these use cases because it will operate on the NICs created by the machine models, because the machine models look at the nd_table[] when they create the NICs. thanks -- PMM
