[Top][All Lists]

[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: Sun, 5 May 2013 23:00:24 +0100

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.

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

-- PMM

reply via email to

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