Re: question on cdevsw_add mask/match

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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@xxxxxxxxxxxxx>