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

[Peter Maydell]

On 6 May 2013 10:24, Michael S. Tsirkin <address@hidden> wrote:
> On Mon, May 06, 2013 at 10:08:42AM +0100, Peter Maydell wrote:
>> 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:

>> > 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?

This still requires users to know what their board's NIC
happens to be, and how do you match up the half-finished
thing created with -device to the device that the board
creates later?

>> >> 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.

> In other words, it's an undocumented hack :(
> Scary as it sounds, for this case I like documenting
> internal names better.

How does that work when both internal NICs are the same kind
of device?

-- PMM