Re: Nested suspends; messages vs. states

Patrick Mochel
2005-03-24T02:35:30Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1697 bytes --]

On Wed, 23 Mar 2005, Alan Stern wrote:

> So what's wrong with changing it into:
>
> void suspend_to_ram()
> {
> lock all devices
> suspend all devices
> turn off main power
> /* Zzzz... */
> resume all devices
> unlock all devices
> }
>
> I agree that your single-semaphore idea would also work to prevent
> unwanted resumes during a system sleep. But it doesn't protect against
> the possibility of devices being removed or added while the PM core is
> traversing its lists. Locking does protect against that -- or rather, it
> will once the mechanisms have been added to the driver model core.

That would add a lot of complication. You never want to add more locks
than you need to. Without locking, each suspend operation is a single
discete action with no dependencies on anything else. Having to lock every
device now intertwines them all in a very complicated and disgusting
manner. It would make it potentially very hard to debug and add a lot of
time to the process.

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!"

Take this from someone that has had to make provably correct shotgun
locking changes to code already in the kernel to appease a screaming Al
Viro (whose usual statement is something along the lines of only "There's
a race in function foo(). You idiot."), and a host of people that believe
his word as gospel by default.

Thanks,

Pat