Re: [PATCH 2/8] PM: suspend_block: Add driver to access suspend blockers from user-space

[Rafael J. Wysocki]

On Tuesday 04 May 2010, Arve Hjønnevåg wrote:
> 2010/5/3 Rafael J. Wysocki <rjw@xxxxxxx>:
> > On Monday 03 May 2010, Arve Hjønnevåg wrote:
> >> On Mon, May 3, 2010 at 8:03 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> >> > On Sunday 02 May 2010, Alan Stern wrote:
> >> >> On Sun, 2 May 2010, Rafael J. Wysocki wrote:
> >> >>
> >> >> > Hmm.  It doesn't seem to be possible to create two different suspend blockers
> >> >> > using the same file handle.  So, what exactly is a process supposed to do to
> >> >> > use two suspend blockers at the same time?
> >> >>
> >> >> Open the file twice, thereby obtaining two file handles.
> >> >
> >> > Well, that's what I thought.
> >> >
> >> > I must admit I'm not really comfortable with this interface.  IMO it would
> >> > be better if _open() created the suspend blocker giving it a name based on
> >> > the name of the process that called it.  Something like
> >> > "<process name>_<timestamp>" might work at first sight.
> >> >
> >> > Alternatively, "<process_name><number>", where <number> is 0 for the first
> >> > suspend blocker created by the given process, 1 for the second one etc., also
> >> > seems to be doable.
> >>
> >> I think it is important to let user-space specify the name. If a
> >> process uses multiple suspend blockers, it is impossible to tell what
> >> each one is used for if they are automatically named.
> >
> > Well, the problem is the only purpose of this is user space debugging, isn't it?
> >
> At the moment, yes.

OK

> But having an explicit init call also simplifies future expansion.

That's irrelevant.  Let's focus _only_ on the "at the moment" part, please.

And BTW, a "future expansion" is not relevant at all to the patchset at hand
and let's work with this assumption from now on.  OK?

> If we ever need to add back multiple types of
> suspend blockers, we can add an init call with a type argument and
> have the current init call use the default type. If the past we have
> had types that keeps the screen on and prevented idle sleep modes. In
> the future we could for instance want to specify if a suspend blocker
> should prevent suspend when the battery is low or when the lid is
> closed.

_If_ we ever do anything like thie, _then_ we will extend the interface.

> > Now, while I don't think it's generally bad to provide kernel interfaces
> > helping to debug user space, I'm not quite sure if that should be done at the
> > expense of the clarity of kernel-user space interfaces.
> >
> > I wonder how many cases there are in which distinguishing between suspend
> > blockers used by the same user space task is practically relevant.
> >
> 
> I think all of them (when more than one suspend blocker is used).

So how many user space processes use more than one suspend blocker right
now on Android?  I'm interested only in the order of magnitude.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/