Re: [PATCH 0/6] [RFC] Proposal for optimistic suspend idea.

[Thomas Gleixner]

On Tue, 27 Sep 2011, John Stultz wrote:
> On Wed, 2011-09-28 at 02:09 +0200, Thomas Gleixner wrote:
> > We have proper mechanisms in place to handle such stuff, but they need
> > proper overall design and definitely a bit more brain usage than just
> > yelling "wakelock".
> 
> And it would be great if some of that brain usage was spent to review
> and critique what I'm actually proposing, rather then just yelling
> "wakelock". :P

Working on it :)
 
> I apologize for being probably too verbose in my mails, but I did
> originally admit that the firmware update issue is a simpler problem and
> doesn't necessarily need the same solution as the races around my
> nightly backups. But I do think that some thought should be put into the
> different use cases that seem to desire similar things, so that an
> appropriate design can be created, instead of a collection of short-term
> hacks.

Yes, we want use cases, which can actually justify something like the
proposed.

Firmware update is _not_ one of them because it needs a proper design
to be completely failsafe and just preventing the box to suspend is
not helping that goal at all. You have to deal with broken network
connections, resets, power outage and more to make it failsafe. And
dealing with all of that covers the unintended suspend already. It
simply does not matter whether it happens or not.

And that's why I'm ranting about such arguments, as they will just
guide people into the delusion of solving hard problems like safe
firmware updates with the wrong mechanisms.

The whole wakelock discussion has been full of delusions from the very
beginning and we really need to eliminate the lunatic arguments so we
can look at the real remaining ones (if any), which might justify
them.

> More brain usage, and proper design. At least with that, I think we
> agree. :)

Right, and proper design does not exclude user space. It very much
starts there.

Thanks,

	tglx
--
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/