From owner-cvs-all@FreeBSD.ORG Sun Jan 29 21:01:21 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5969616A425; Sun, 29 Jan 2006 21:01:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDA8543D46; Sun, 29 Jan 2006 21:01:20 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0239E46BCD; Sun, 29 Jan 2006 16:01:12 -0500 (EST) Date: Sun, 29 Jan 2006 21:03:00 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <43DD2555.8080408@elischer.org> Message-ID: <20060129205952.E95776@fledge.watson.org> References: <200601291539.k0TFd93N068882@repoman.freebsd.org> <43DD2555.8080408@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Ed Maste , cvs-all@FreeBSD.org Subject: Re: 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 ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2006 21:01:21 -0000 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