On Mon, May 06, 2013 at 10:08:42AM +0100, Peter Maydell wrote: > [cc'd Anthony since this has drifted into a more general topic] > > On 6 May 2013 09:51, Michael S. Tsirkin <m...@redhat.com> wrote: > > 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? > > I don't think this will work, because -device does both > 'instance_init' and 'realize', and some of the things the > board needs to set and wire up must be done before 'realize'.
Well let's add a flag that tells QM to delay realize then? It's not "abstract" but maybe "embedded" type? > >> 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. > > Well, it gets mapped to a specific device (hopefully we pick > the same order as the kernel so first nic is eth0, second > is eth1, and so on). This isn't a question of initialization > order, because you can happily initialize the NIC corresponding > to nd_table[1] before the one for nd_table[0] if you like. > It's just a matter of picking which bit of hardware we call > the "first" ethernet device, in the same way that we pick > one of two serial ports to call the "first" serial port. > > thanks > -- PMM In other words, it's an undocumented hack :( Scary as it sounds, for this case I like documenting internal names better.
