cvs commit: src/sys/dev/ath if_ath.c src/sys/dev/awi awi.c src/sys/dev/bfe if_bfe.c src/sys/dev/bge if_bge.c src/sys/dev/ed if_ed.c src/sys/dev/em if_em.c src/sys/dev/ex if_ex.c src/sys/dev/fe if_fe.c src/sys/dev/fxp if_fxp.c src/sys/dev/gem ...

[Robert Watson]

On Sun, 29 Jan 2006, Julian Elischer wrote:

>>   Note that with these changes, these drivers now depend on locking the 
>> global
>>  if_addr_mtx, so binary modules of these drivers will not work on 5.4 or
>>  earlier releases.
>
> Is the converse true?
>
> i.e. can older binaries (e.g. from 5.4) work on 5.5?
>
> this is a "must"

Yes.  The "problem" is that modules using the new locking will reference a new 
global symbol, if_addr_mtx.  Old modules will continue to load fine, and 
continue to not have locking around their manipulation of the multicast 
address lists, so will not work worse than they did before.  New modules build 
from our kernel tree will have the new symbol reference -- vendor drivers that 
don't have the locking but are built on new systems will continue to work fine 
on old kernels, but it is desirable for vendors to add the locking to avoid 
race conditions in multicast address management, which can be observed in the 
wild when using multicast moderately heavily.

The version of multicast address locking merged to RELENG_5 by Ed is actually 
a fairly modified version of the code I originally committed to HEAD -- I 
added an if_addr_mtx field to struct ifnet, which is used for synchronizing 
per-ifnet address lists.  We didn't want to modify struct ifnet in RELENG_5, 
so he added a global mutex which is accessed by the macros instead, giving 
driver source compatibility with RELENG_6 and HEAD, but avoiding changes to 
struct ifnet.

I.e., I think all is fine.

Robert N M Watson