From owner-cvs-all@FreeBSD.ORG Fri Apr 25 10:47:09 2003 Return-Path: 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 8EB3737B405 for ; Fri, 25 Apr 2003 10:47:09 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D62E43FDD for ; Fri, 25 Apr 2003 10:47:08 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 65487 invoked by uid 1000); 25 Apr 2003 17:47:09 -0000 Date: Fri, 25 Apr 2003 10:47:09 -0700 (PDT) From: Nate Lawson To: Sam Leffler In-Reply-To: <06fe01c30b42$66705210$52557f42@errno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 25 Apr 2003 17:47:10 -0000 On Fri, 25 Apr 2003, Sam Leffler wrote: > > For developers, note that the locking in the code path only protects the > > various fxp routines (fxp_start, fxp_intr, fxp_tick, ...) and is not > > intended to serialize access to ANY external structures. This is how it > > should be. Please do not copy the exact approach taken here for a little > > while until ifnet locking is finished as there may need to be some changes > > made to this model. > > This doesn't make much sense to me. I've locked numerous chunks of code and > used a totally different approach: synchronize access to data structures, > not code paths. Perhaps you and Jeffrey Hsu need to have a private > discussion... I wrote the comment at 2 am so let me rephrase this: I am not locking the code path. I am locking the softc, device registers, and any resources shared _within_ the driver. I am NOT locking ifp accesses or other external objects. This work is merely the driver end node locking and makes as few assumptions about the outside world as possible. However, I did not make a huge effort to refactor the code path and as such, the locking is not nearly fine-grained enough to be called a finished product. For instance, fxp_intr() holds sc->sc_lock for the entire duration of the routine as it accesses various card registers and softc variables throughout. It may make sense to lock/unlock the softc multiple times and refactor fxp_intr() to allow this but on the other hand, this may require too many mutex operations. The only way to tell is by testing and profiling. I have posted this work in progress over the course of the past two weeks and it has been reviewed in various states by gallatin@ and mux@. My approach is extremely similar to one gallatin@ sent me. I would appreciate any specific input from hsu@ or others to improve this code. -Nate