question on cdevsw_add mask/match
dillon at apollo.backplane.com
Sun Mar 20 11:59:59 PST 2005
: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
: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.
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
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.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel