From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZHfC-0007Q9-7p for qemu-devel@nongnu.org; Mon, 06 May 2013 05:24:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZHf7-0007Wq-V1 for qemu-devel@nongnu.org; Mon, 06 May 2013 05:24:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZHf7-0007Wi-Nf for qemu-devel@nongnu.org; Mon, 06 May 2013 05:24:49 -0400 Date: Mon, 6 May 2013 12:24:31 +0300 From: "Michael S. Tsirkin" Message-ID: <20130506092431.GA16158@redhat.com> References: <6476d358d7f54aa7db6b7dc435d010bc83b2e806.1367676178.git.jcd@tribudubois.net> <20130505174902.GA7861@redhat.com> <20130505211502.GC7861@redhat.com> <20130506085106.GA15909@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: Anthony Liguori , qemu-devel@nongnu.org, peter.crosthwaite@xilinx.com, Jean-Christophe DUBOIS , peter.chubb@nicta.com.au, afaerber@suse.de 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 wrote: > > 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? > > 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.