Re: [Qemu-devel] [PATCH v2 1/4] Add i.MX FEC Ethernet driver

[Michael S. Tsirkin]

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 <address@hidden> wrote:
> > On Sun, May 05, 2013 at 11:00:24PM +0100, Peter Maydell wrote:
> >> On 5 May 2013 22:15, Michael S. Tsirkin <address@hidden> 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.