Re: Attempted summary of suspend-blockers LKML thread
From: Rafael J. Wysocki
Date: Sun Aug 08 2010 - 15:19:30 EST
On Saturday, August 07, 2010, Arve Hjønnevåg wrote:
> 2010/8/7 Arve Hjønnevåg <arve@xxxxxxxxxxx>:
> > 2010/8/7 Rafael J. Wysocki <rjw@xxxxxxx>:
> >> On Saturday, August 07, 2010, Arve Hjønnevåg wrote:
> >>> 2010/8/6 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> >>> > On Thu, 5 Aug 2010, Arve Hjønnevåg wrote:
> ...
> >>> >> total_time, total time the wake lock has been active. This one should
> >>> >> be obvious.
> >>> >
> >>> > Also easily added.
> >>> >
> >>> Only with a handle passed to all the calls.
> >>
> >> Well, I'm kind of tired of this "my solution is the only acceptable one"
> >> mindset. IMHO, it's totally counter productive.
> >>
> >
> > How do you propose to track how long a driver has blocked suspend when
> > you have an unblock call that takes no arguments.
> >
>
> Also, I did not not see a response to my question about why you don't
> want to pass a handle.
It doesn't really matter what I personally want. In fact, I'm not totally
opposed to that idea, although there are disadvantages (eg. a "handle"
would really mean a pointer to an object with certain life cycle that needs to
be managed by the caller and it's not that clear to me who should manage the
objects that the PCI wakeup code would pass to pm_wakeup_event(), for one
example). I sent a pull request for your original patchset to Linus after all. :-)
I said I didn't think "it would fly", meaning that I was afraid the other kernel
developers wouldn't like that change.
The reason why I think so is that you'd like to add a whole new infrastructure
whose only purpose would be debugging that would only be useful to systems
using opportunistic suspend. That, however, is only Android right now and it
cannot use the mainline kernel for other reasons, so basically we would add
infrastructure that's useful to no one.
Thanks,
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/