Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 4633 bytes --]

On Tue, 18 Oct 2011 00:02:30 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Monday, October 17, 2011, NeilBrown wrote:
> > On Sun, 16 Oct 2011 00:10:40 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> ...
> > > 
> > > >  But I think it is very wrong to put some hack in the kernel like your
> > > >    suspend_mode = disabled
> > > 
> > > Why is it wrong and why do you think it is a "hack"?
> > 
> > I think it is a "hack" because it is addressing a specific complaint rather
> > than fixing a real problem.
> 
> I wonder why you think that there's no real problem here.
> 
> The problem I see is that multiple processes can use the suspend/hibernate
> interfaces pretty much at the same time (not exactly in parallel, becuase
> there's some locking in there, but very well there may be two different
> processes operating /sys/power/state independently of each other), while
> the /sys/power/wakeup_count interface was designed with the assumption that
> there will be only one such process in mind.

Multiple process can write to your mail box at the same time.  But some how
they don't.  This isn't because the kernel enforces anything, but because all
the relevant programs have an agreed protocol by which they arbitrate access.
One upon a time this involved creating a lock file with O_CREAT|O_EXCL.
These days it is fcntl locking.  But it is still advisory.

In the same way - we stop multiple processes from suspending/hibernating at
the same time by having an agreed protocol by which they share access to the
resource.  The kernel does not need to be explicitly involved in this.

...

> > > Well, I used to think that it's better to do things in user space.  Hence,
> > > the hibernate user space interface that's used by many people.  And my
> > > experience with that particular thing made me think that doing things in
> > > the kernel may actually work better, even if they _can_ be done in user space.
> > > 
> > > Obviously, that doesn't apply to everything, but sometimes it simply is worth
> > > discussing (if not trying).  If it doesn't work out, then fine, let's do it
> > > differently, but I'm really not taking the "this should be done in user space"
> > > argument at face value any more.  Sorry about that.
> > 
> > :-)  I have had similar mixed experiences.   Sometimes it can be a lot easier
> > to get things working if it is all in the kernel.
> > But I think that doing things in user-space leads to a lot more flexibility.
> > Once you have the interfaces and designs worked out you can then start doing
> > more interesting things and experimenting with ideas more easily.
> > 
> > In this case, I think the *only* barrier to a simple solution in user-space
> > is the pre-existing software that uses the 'old' kernel interface.  It seems
> > that interfacing with that is as easy as adding a script or two to pm-utils.
> 
> Well, assuming that we're only going to address the systems that use PM utils.

I suspect (and claim without proof :-) that any system will have some single
user-space thing that is responsible for initiating suspend.
Every time I look at one I see a whole host of things that need to be done
just before suspend, and other things just after resume.
They used to be in /etc/apm/event.d.  Now there are
in /usr/lib/pm-utils/sleep.d.  I think they were in /etc/acpid once.
I've seen one thing that uses shared-library modules instead of shell scripts
on the basis that it avoids forking and goes fast (and it probably does).
But I doubt there is any interesting system where writing to /sys/power/state
is the *only* thing you need to do for a clean suspend.
So all systems will have some user-space infrastructure to support suspend,
and we just need to hook in to that.


> 
> > With that problem solved, experimenting is much easier in user-space than in
> > the kernel.
> 
> Somehow, I'm not exactly sure if we should throw all kernel-based solutions away
> just yet.

My rule-of-thumb is that we should reserve kernel space for when
  a/ it cannot be done in user space
  b/ it cannot be done efficient in user space
  c/ it cannot be done securely in user space

I don't think any of those have been demonstrated yet.  If/when they are it
would be good to get those kernel-based solutions out of the draw (so yes:
keep them out of the rubbish bin).

So I'd respond with "I'm not at all sure that we should throw away an
all-userspace solution just yet".  Particularly because many of us seem to
still be working to understand what all the issues really are.

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]