On Thu, 24 Mar 2005, Alan Stern wrote:
> On Wed, 23 Mar 2005, Patrick Mochel wrote:
> > It would make it potentially very hard to debug and add a lot of
> > time to the process.
>
> Hard to debug, maybe... we can't tell without actually trying. Adding a
> lot of time to the suspend process, no. Acquiring the locks would block
> only for things that should cause you to block anyway, like trying to
> suspend a device while it's being probed.
It would change the locking from an O(1) operation to an O(n) operation,
where n is the number of devices. Taking any lock is not cheap, so taking
N locks, when is N is large is going to be grossly inefficient.
> (Or did you mean it would add a lot of time to the development process? I
> doubt it, but it would force people to think about issues they would
> prefer to ignore.)
Uh, I hadn't thought about it, but yes, that's true as well. While in
theory it's good to make people think about what they're doing, you want
to make things as simple as possible for people to implement ("Make it
impossible to get wrong."). Especially for driver writers, who typically
have the least experience with the Linux kernel, and in many cases, very
little experience with multi-processor systems and race conditions.
[ Note that it's still easy to get things wrong in the driver model, but
that's specifically where the effort is going - to make it harder to mess
up. ]
> > Note that you're locking ideas are at least original, but I'm having a
> > harder and harder time taking them seriously without any code. I highly
> > recommend that you at least try to codify the locking changes before
> > making suggestions. It will weed out a lot of under-cooked ideas and get
> > us a lot closer to a workable solution. As Linus would say "Show me the
> > code!"
>
> A large part of the concept is already coded up and part of the kernel
> since about 2.6.9, and it works quite well. Its scope is currently
> restricted to the USB layer; I'm proposing to make it more general.
Really? And it works well? Greg, David? What do you guys think of it?
> In fact at this stage it's more a matter for discussion under the topic
> of driver-model development, so I'm going to stop talking about it on
> linux-pm. You indicated that you had some relevant driver-model patches
> -- would you like to send them to me?
I apologize, I assumed you had seen them. You can find them here:
http://article.gmane.org/gmane.linux.kernel/289092
specifically the klist patch:
http://article.gmane.org/gmane.linux.kernel/289090
Pat
