cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h

[Nate Lawson]

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 at .  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