re: devsw_detach is failing -- is this a manifestation of PR kern/56962?

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello Matthew.  That line assures that if a device driver has unloaded and reloaded its
bdevw or cdevw interfaces, it gets assigned the same major numbers that they had when they
were first loaded on the system.  If a device driver has never loaded its bdevsw or cdevsw
interfaces on a system and the major number is dynamically assigned, this works as well because
execution of the for loop exits due to there being an insufficient number of conv structures
available when the device driver loads for the first time, so this test is never executed.
Once the driver loads for the first time, the conv structure is initialized with the correct
major numbers and this test will pass the next time the device driver loads its bdevsw or
cdevsw interfaces.  There is one caveat here that was always true, but will absolutely be
enforced with this patch.  That is, the caller of devsw_attach() should ensure the bmajor and
cmajor numbers they pass into the function point to different variables in their function, even
if they do not implement the bdevsw interface.  If they fail to do this, they'll get EINVAL
back from the devsw_attach call if they load their bdevsw or cdevsw interfaces on the system
more than once.  

-thanks
-Brian

On Feb 13,  2:47pm, matthew green wrote:
} Subject: re: devsw_detach is failing -- is this a manifestation of PR kern
} your change seems to fix a clear but to me.
} 
} > -		if (*bmajor < 0)
} > +		if ((bdev != NULL) && (*bmajor < 0)) 
} >  			*bmajor = conv->d_bmajor;
} 
} there's also this line i'm curious about, just below:
} 
}                 if (*bmajor != conv->d_bmajor || *cmajor != conv->d_cmajor) {
}                         error = EINVAL;
}                         goto out;
} 
} should the first part also depend upon either bdev != NULL or
} perhaps (*bmajor >= 0 && bdev == NULL) as the following code
} uses...
} 
} 
} .mrg.
>-- End of excerpt from matthew green