qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2 1/4] Add i.MX FEC Ethernet driver
Date: Mon, 6 May 2013 10:08:42 +0100

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]