On 2011-05-20 18:04, Peter Maydell wrote: > 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()
You mean qemu_new_nic? Otherwise it wouldn't help. Will have a look to move that over. > 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().) I don't disagree that nd_table is better removed. Then let's address all those issues separately. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
