svn commit: r192535 - head/sys/kern
John Baldwin
jhb at freebsd.org
Fri May 22 15:54:26 UTC 2009
On Friday 22 May 2009 11:37:38 am Scott Long wrote:
> 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.
Are you referring to the sysctl thing? That was quite trivial to fix FWIW. I
also do not see why make_dev_sched() with a callback won't work? We already
have this exact policy limitation in many similar APIs such as if_attach().
Another thing to consider is that if you hold a lock while calling into other
subsystems, that can result in your lock being held for a relatively "long"
time which increases the chances for lock contention.
--
John Baldwin
More information about the svn-src-all
mailing list