Date: Fri, 25 Apr 2003 10:47:09 -0700 (PDT) From: Nate Lawson <nate@root.org> To: Sam Leffler <sam@errno.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <Pine.BSF.4.21.0304251032540.65457-100000@root.org> In-Reply-To: <06fe01c30b42$66705210$52557f42@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0304251032540.65457-100000>