On Sun, May 05, 2013 at 11:00:24PM +0100, Peter Maydell wrote: > 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.
Can't board code look for instanciated controllers and wire them up? > > 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 How does it work now? I am guessing each -net nic gets mapped to a random device. At some level that's worse than documenting about internal names, we are teaching users to learn order of initialization by trial and error and then rely on this. > * 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 -- MST