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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
