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

Nate Lawson nate at
Fri Apr 25 11:06:08 PDT 2003

On Fri, 25 Apr 2003, Jeffrey Hsu wrote:
>   > 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.
> These locks are an example of local SMP locking.  It is simply not
> possible to correctly reason about SMP locally.
> 							Jeffrey

Please see my email on cvs-all about this.  I am not attempting to reason
about the "outside world" with the locking.  I am merely trying to protect
access by fxp functions to fxp shared data (i.e. softc, driver registers,
etc.)  I am not trying to serialize IF_DEQUEUE access or such.

My code makes the following assumptions:
* Entries are fxp_start, fxp_intr, fxp_tick, fxp_init, fxp_ioctl, and
fxp_poll.  No one will call fxp except through those routines.
* All the above functions access fxp shared data throughout the entire
function, therefore it will take more testing and refactoring of the code
path to allow multiple locks/unlocks if so desired.  Therefore, for
now, hold the fxp lock for most of the routine.
* It is not harmful to call outside functions (i.e. ifnet) with a local
fxp lock held.  Note that I am _not_ attempting to serialize access to
outside functions by holding the fxp lock across them.

Please explain (including details) if any of the above assumptions are
going to be invalidated by your locking work. I fully understand that
ifnet locking is not complete and that another thread may access ifp while
fxp is accessing it.  I am not attempting to prevent this and I left
MPSAFE disabled because of this.

Jeffrey, you've made short comments in private email like the one above
but they seem orthogonal to the code I just committed.  Please explain so
I can modify my approach if necessary.


More information about the cvs-all mailing list