cdevsw_add() vs make_dev()

[Matthew Dillon]

:In my continuing quest to port a driver from Free to DFly, I've run
:into something I don't understand with the device structures. In Free,
:if the driver exported an ioctl interface, it defined the ioctl
:handler in struct cdevsw and called something like
:
:make_dev(&svd_cdevsw, device_get_unit(dev), UID_ROOT,
:	GID_OPERATOR, 0600, "%s", device_get_nameunit(dev));
:
:Doing this on DFly doesn't seem sufficient. Apps making an ioctl to
:this device error out on the open with a 'Device not configured' error
:message. Investigating a little, I found that other drivers added a
:call to
:
:cdevsw_add(&svd_cdevsw, -1, device_get_unit(dev));
:
:What is this call doing differently than what make_dev provides?
:
:-- 
:Chuck Tuffli
:Agilent Technologies

    Devices in FreeBSD-4 and DragonFly have major and minor numbers (in
    FreeBSD-5 they are trying to do away with major numbers but, personally
    speaking, I think that's silly).

    In anycase, in FreeBSD-4 there is no real device hierarchy for cutting
    up a major number into multiple minor-based devices.  Things
    such as /dev/null and /dev/urandom, which share the same major number,
    are basically hacks.  It is also possible to crash FreeBSD-4 by creating
    devices with illegal minor numbers, and overriding a device (the disk
    layer) is a huge hack.

    In DragonFly the device is required to call cdevsw_add() with a
    minor number 'mask and match' in order to reserve its device space.
    If a clone function exists DragonFly will call the clone function for
    any device opens within the reserved space.  A device may also call
    make_dev() to slice out and name particular minor numbers within its
    registered reserved space and, eventually, we will use make_dev() to
    support a DragonFly devfs (but it's last on my list of things to do).

    This DFly methodology has the ability to easily slice out portions
    of the minor number address space, to reserve a sub-area for which
    the clone function will be called, to override a device space with
    another device space (which is how the disk layering works instead
    of all the terrible hacks FreeBSD-4 does), and to properly dispose of
    devices within the device space when a device is closed or unloaded.
    And a bunch of other things.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>