svn commit: r192535 - head/sys/kern

[Scott Long]

John Baldwin wrote:
> On Friday 22 May 2009 9:44:18 am Scott Long wrote:
>> John Baldwin wrote:
>>> On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote:
>>>> At this point I wonder what's the purpose of maintaining the sleeping
>>>> version for such functions?
>>> Actually, I still very much do not like using M_NOWAIT needlessly.  I would 
>>> much rather the solution for make_dev() be that the 1 or 2 places that need 
>>> to do it with a mutex held instead queue a task to do the actual make_dev() 
>>> in a taskqueue when no locks are held.  This is basically what 
>>> destroy_dev_sched() is doing.  Perhaps a make_dev_sched() with a similar 
>>> callback to be called on completion would be better.  Having a device driver 
>>> do all the work to setup the hardware only to fail to create a node in /dev 
>>> so that userland can actually use it is pretty rediculous and useless.
>>>
>> It's a lot easier for me to handle a failure of make_dev in CAM than it 
>> is to decouple the call to it.  Please don't dictate policy.
> 
> But what is there for CAM to handle?  I would expect CAM to handle hardware
> events such as the devices arriving or leaving.  A temporary memory shortage
> it not a hardware event.  As a user, if I insert a USB stick when the system
> happens to be temporarily low on memory, is it more useful for the cdev to
> appear a few microseconds later from a deferred context once memory is
> available or for no device to ever appear at all?
> 

John,

You yourself have been recently burned by not fully understanding the
complexity involved in CAM.  By changing all of the periph drivers to
conform to an artificial policy limitation of the make_dev call, I face
a significant amount of time and effort to rewrite and test code paths
that are, unfortunately, highly complex and very fragile.  Please just
make a simple concession.

Scott