[lkml]   [2009]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFD] Automatic suspend
On Tue, Mar 3, 2009 at 5:57 AM, Pavel Machek <> wrote:
> Hi!
>> >> If you ignore wakelocks with timeouts, the current
>> >> wakelock interface can be implemented with a global atomic_t to
>> >> prevent suspend, and a per wakelock atomic_t to prevent a single
>> >> client from changing the global reference count by more than one.
>> >>
>> >> There are a couple of reasons that I have not done this. It removes
>> >> the ability to easily inspect the system when it is not suspending.
>> >
>> > Care to elaborate?
>> If you have a single atomic_t and it is not 0, you do not know who
>> incremented it.
> Which is okay for already debugged system. For debugging, yes some
> support can be nice.

Yes, but installing an app can turn your debugged system into an
undebugged system. I think is fine to have a kernel option to disable
all debugging support, I just don't think it is the top priority. I
have two options for making the no-stats no-timeout configuration
faster. Option one, always use a reference count, and implement the
other configurations on top of this. This makes the shipping
configuration slower. Option two, use a completely separate
implementation when stats or timeouts are enabled. This makes the fast
version virtually untested. Neither of these are very appealing at the

Arve Hjønnevåg
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-03-04 00:55    [W:0.197 / U:9.692 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site