From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZH8p-0001Su-1h for qemu-devel@nongnu.org; Mon, 06 May 2013 04:51:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZH8m-0005El-Bg for qemu-devel@nongnu.org; Mon, 06 May 2013 04:51:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZH8m-0005EU-2u for qemu-devel@nongnu.org; Mon, 06 May 2013 04:51:24 -0400 Date: Mon, 6 May 2013 11:51:06 +0300 From: "Michael S. Tsirkin" Message-ID: <20130506085106.GA15909@redhat.com> References: <6476d358d7f54aa7db6b7dc435d010bc83b2e806.1367676178.git.jcd@tribudubois.net> <20130505174902.GA7861@redhat.com> <20130505211502.GC7861@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2 1/4] Add i.MX FEC Ethernet driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: peter.crosthwaite@xilinx.com, Jean-Christophe DUBOIS , peter.chubb@nicta.com.au, qemu-devel@nongnu.org, afaerber@suse.de On Sun, May 05, 2013 at 11:00:24PM +0100, Peter Maydell wrote: > On 5 May 2013 22:15, Michael S. Tsirkin 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? > > 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. > * 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 > nd_table[] > * 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. > > thanks > -- PMM -- MST