Re: question on cdevsw_add mask/match
:This is what I used as an example
: sys/dev/disk/isp/isp_freebsd.c:207
:
:Some of the others that look similar (there are more on this list)
: sys/bus/usb/usb.c:327
: sys/dev/agp/agp.c:263
: sys/dev/disk/fd/fd.c:1030
: sys/dev/disk/wt/wt.c:269
: sys/dev/drm/drm_drv.h:657
: sys/dev/misc/dcons/dcons_os.c:611
: sys/dev/misc/gpib/gpib.c:140
: ...
:
:One driver that might be doing things correctly is
: sys/dev/misc/psm/psm.c:1254
:(see definition of PSM_MKMINOR at line 133)
:
:--
:Chuck Tuffli
:Agilent Technologies
Well, psm generates a mask other then -1 because it needs to break
the minor device space down for multiple devices per unit, whereas
e.g. agp/agp.c only needs one unit so the match mask can be -1 (match
all bits against the specified unit number). -1 is the most restrictive
mask that can be used, the unit number must *exactly* match the minor
device number for the system to recognize the (major,minor) as belonging
to the device.
If we look at the ISP case, what is being registered is e.g. /dev/isp0,
/dev/isp1, etc... each unit is being registered separately and only
one device entry for each needs to be registered. Unlike FreeBSD
raw block device registrations are not overloaded with the disk
management registrations (which would be e.g. isp0s1, isp0s1a, etc).
Going back to PSM again, here is an example of how the mask and match
works:
MASK: -------- -------- -------1 11111110
MATCH: -------- -------- -------U UUUUUUU?
This means that the (one) cdevsw_add() is registrating a minor device
space for the particular unit U that allows bit 0 of the minor number
to be anything, yielding two devices within the device range.
These devices are then regstered using two make_dev() calls that just
follow the cdevsw_add().
The MSB bits in this case currently wind up being 0 due to the way the
PSM_MKMINOR() macro is designed, which means that it is in fact possible
to have an aliasing effect (those bits can be anything and still match).
If anything I would say that is a bug in the PSM registration, but as
far as bugs go its fairly irrelevant if nothing else is sharing the
major number with PSM (and nothing else is). It's really an artifact
from the original PSM driver which 'only' supports 256 PS/2 mice, I was
doing a mass migration to the new API and couldn't afford to spend an
hour on each module removing silly (and already very generous) limits.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 4 之 6 篇)：