cvs commit: src/sys/dev/an if_an.c src/sys/dev/arl if_arl_isa.c
src/sys/dev/awi if_awi_pccard.c src/sys/dev/cm if_cm_isa.c
src/sys/dev/cnw if_cnw.c src/sys/dev/cp if_cp.c
src/sys/dev/cs if_cs.c src/sys/dev/ed if_ed.c src/sys/dev/em
gallatin at cs.duke.edu
Thu Sep 22 13:44:42 PDT 2005
Robert Watson [rwatson at FreeBSD.org] wrote:
> Would if_dead simply replace the function vector, or would it also drain
> threads currently in those functions? We have a pervasive problem with
> dead functions that fail to drain (phk has fixed this up for cdev, I
> believe, and colin for callouts, but there are many others), and without
> that there may be problems. However, if adding draining and refcounting
> on entering ifnet methods, we need to be very cautious about the
> performance impact.
The if_dead() method is basically what MacOSX does. The device
operations are replaced by an dlil_recycle_$NAME, which drop
packets, return EOPNOTSUPP, etc.
I'd hate to see us overhead in the transmit routine to do reference
counting to protect against a race which can only happen on detach,
which is quite rare. Replacing if_output and sleeping a second or two
to wait for threads to drain should solve 99.99% of the races.
Nothing in if_output should be blocking, so I don't see the need for
For ioctl, just put a lock around all calls into ifp->if_ioctl(), and
make sure if_dead grabs that lock before replacing if_ioctl(). Nobody
cares about if_ioctl() performance do they?
Maybe my viewpoint is too restricted, because I have never had to deal
with an mii, or hardware that does really dumb stuff...
More information about the cvs-src