On 6 May 2013 10:24, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, May 06, 2013 at 10:08:42AM +0100, Peter Maydell wrote: >> On 6 May 2013 09:51, Michael S. Tsirkin <m...@redhat.com> wrote: >> > On Sun, May 05, 2013 at 11:00:24PM +0100, Peter Maydell wrote: >> >> On 5 May 2013 22:15, Michael S. Tsirkin <m...@redhat.com> 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