On 20 May 2011 16:55, Jan Kiszka <jan.kis...@siemens.com> wrote: > On 2011-05-20 17:49, Peter Maydell wrote: >> This patchset reverts commit f68b9d672, which was triggering >> spuriously for NICs created via -device rather than -net nic. >> It then reimplements the improved diagnostics with a different >> approach which only applies to '-net nic'. (It's only -net nic >> devices that can be ignored (ie not instantiated); -device >> nic devices are always instantiated. Checking for -device user >> errors like "this device wasn't plugged into any bus" is >> a separate issue not addressed here.) > > But we still have the problem that qemu_new_nic does not call > net_init_nic. That means e.g. that NICs instantiated via -device don't > participate in automatic MAC assignment. Maybe fixing that makes this > series obsolete.
I think that avoiding MAC address clashes should be done by having net_init_nic() call qemu_macaddr_default_if_unset() rather than doing its own MAC assignment. Having qemu_new_nic() call net_init_nic() is a bit tricky because (a) as you said earlier you need to avoid doing it for NICs which were created from nd_table entries in the first place and (b) it imposes a new limit on the number of NICs you can create via -device which wasn't there before (because nd_table is fixed size). I think I agree with Paul Brook's comment on IRC that the real long term solution is for nd_table[] to go away completely, (ie not for the new qdev option code to add entries in nd_table[] by calling net_init_nic().) -- PMM
