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 if_em.c ...

[Andrew Gallatin]

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
real refcounting.

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

Drew