Re: Device layering work patch #3

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Are you sure about the patch to bktr_os.c? Doesn't the cdevsw_remove
:destroy all devices, even if there are multiple bktr(4) devices in the
:tree? I haven't check the rest yet.
:
:Joerg

    This is turning out to be the final piece of the puzzle.  I am augmenting
    cdevsw_add() and cdevsw_remove() to include a minor number mask and match
    argument.  cdevsw_add() will only allow devices to be created within the
    specified domain and cdevsw_remove() will only destroy devices within
    the specified domain.

    FreeBSD has been swinging back and forth between requiring or not 
    requiring the use of cdevsw_add().  For example, FreeBSD-5 only has
    make_dev(), while FreeBSD-4 (and DFly) uses both make_dev() and 
    cdevsw_add() (but sometimes forgets to call cdevsw_add()).

    For DragonFly, I am going to require the use of cdevsw_add() but by giving
    it a minor number mask and match value, cdevsw_add() now becomes 
    responsible for managing the domain of device numbers that fall within
    the registration.  So, for example, when CAM registers "da0" that
    domain includes "da0[s0-3]{a-o}".  And we won't get 'garbage' devices
    lying around from userland attempts to access non-existant units.

    Not only does that solve the multiple unit issue, it also makes it
    possible to have distinct device drivers (each with its own cdevsw)
    share the same major number by using different domains within the 
    minor number specification.

    So, for example, it would be possible to register disparate devices using
    generic major numbers.  e.g. "eth%d" or "lpt%d" (regardless of the actual
    device).  I can definitely see uses for this beyond the current device
    infrastructure.

    I'll have another patch ready this afternoon or evening. 

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>