question on cdevsw_add mask/match

[Matthew Dillon]

:I'm a little confused as how to correctly specify mask and match for
:cdevsw_add() and cdevsw_remove(). There are a number of drivers that
:specify mask and match similar to the following
:
:cdevsw_add(&isp_cdevsw, -1, device_get_unit(isp->isp_dev));
:
:(not to single out the QLogic driver ;^) ). The problem with this
:specification is on a kldunload, the kernel will spit out the
:following
:
:svd(202)[ffffffff/00000000]: Warning: cdevsw_remove() called while 1 device refs still exist!
:
:because destroy_all_dev() uses the mask (0xffffffff) on dev->si_udev
:and compares it to the match value (0) which won't match because
:si_udev is a combination of the major and minor numbers (0xca00 in the
:above case) and not the unit number.
:
:The question is what is the correct way to specify mask/match? In my
:case, 0/0 "works" but I wasn't sure if that specification is correct.
:
:-- 
:Chuck Tuffli
:Agilent Technologies

     The mask/match is to deal with distinct devices which share the same
     major number.  Most devices completely own their major number and
     use a mask of 0 and a match of 0 (which means that ALL minor numbers
     for that major are recognized as belonging to the device).  This is
     'legacy' operation.

     The goal is to specify a minor number mask that is appropriate, so
     e.g. when the USB device registers a unit it uses a mask of -1 (match
     all minor number bits) and a minor number representing the unit.

     The mask only applies to the minor number space.  callers of e.g.
     cdevsw_get() pass a major and minor, typically using uminor() to
     generate the minor number.  uminor() masks-out the major bits so only
     the minor bits are left (it doesn't shift them back, it just zero's
     out the bits related to the major part of the device number).

     If you give a me a filename and line number where you think the
     cdevsw_remove() is incorrect, I will take a look at it.  The above
     warning typically occurs if there are still references to devices
     undelrying the cdevsw that is being destroyed.  The devices are
     rerouted to the bit bucket, but the case is not supposed to happen
     for correctly written device drivers.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>