Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler <florian@mickler.org>]

On Wed, 2 Jun 2010 21:02:24 +1000
Neil Brown <neilb@suse.de> wrote:
> 
> And this decision (to block suspend) really needs to be made in the driver,
> not in userspace?

Well, it fits. The requirement is a direct consequence of the intimate
knowledge the driver has about the driven devices. 
Or if you get in an upper layer, the knowledge that the subsystem has
about it's requirements to function properly. Why would you separate it out?

If all your drivers specify their needed requirements, the pm-core (or
idle) has the maximum flexibility to implement any strategy and is
guaranteed a stable system as long as it honours the given requirements.
(That's the theory, of course.)

> 
> You could get those drivers to return EBUSY from PM_SUSPEND_PREPARE (which
> would need to be a configurable option), but then I guess you have no way to
> wait for the device to become non-busy.
> 
> If user-space really cannot tell if the driver is busy or not, then I would
> suggest that the driver is fairly poorly designed.

In general, userspace has no business knowing if the driver is busy or
not. It would need intimate knowledge about the driver to determine if
it is busy or not. That is what the kernel is all about, to hide that
knowledge from userspace and masking it with a one-fits-all-API.


> 
> It would seem then that a user-space requested suspend is not sufficient for
> your needs even if we remove the race window, as you have drivers that want
> to avoid suspend indefinitely, and that "need to avoid suspend" status is not
> visible from user-space.

Well, but the kernel-solution and the userspace solution should be
pretty independent. The tricky part here seems to be to have a
kernel-userspace-boundary that doesn't require a specific kernel
implementation and works. 

Could someone perhaps make a recap on what are the problems with the
API? I have no clear eye (experience?) for that (or so it seems).

> It is a pity that this extra requirement was not clear from your introduction
> to the "Opportunistic suspend support" patch.

I think that the main problem was that _all_ the requirements were
not communicated well.  That caused everybody to think that their
solution would be a better fit. You are not alone.
 
> If that be the case, I'll stop bothering you with suggestions that can never
> work.
> Thanks for your time,
> NeilBrown

Don't be frustrated. What should Arve be?  :)

Cheers,
Flo