Re: cdevsw_add() vs make_dev()
: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@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 2 之 5 篇)：