Messages in this thread | | | Date | Mon, 3 May 2010 21:01:36 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH 1/8] PM: Add suspend block api. |
| |
Hi!
> > > > As I explained before (and got no reply), the proposed interface is > > > > ugly. It uses one sysfs file to change semantics of another one. > > > > > > In fact this behavior was discussed at the LF Collab Summit and no one > > > involved had any problem with that. > > > > Well, I explained why I disliked in previous mail in more details, > > We do exactly the same thing with 'pm_test', so I'm not sure what the problem is. > > > and neither you nor Arve explained why it is good solution. > > Because it's less confusing. Having two different attributes returning > almost the same contents and working in a slightly different way wouldn't be > too clean IMO.
No, I don't think it is similar to pm_test. pm_test is debug-only, and orthogonal to state -- all combinations make sense.
With 'oportunistic > policy', state changes from blocking to nonblocking (surprise!). Plus, it is not orthogonal:
(assume we added s-t-flash on android for powersaving... or imagine I get oportunistic suspend working on PC --I was there with limited config on x60).
policy: oportunistic forced
state: on mem disk
First disadvantage of proposed interface is that while 'opportunistic mem' is active, I can't do 'forced disk' to save bit more power.
Next, not all combinations make sense.
oportunistic on == forced <nothing>
oportunistic disk -- probably something that will not be implemented any time soon.
oportunistic mem -- makes sense.
forced on -- NOP
forced mem -- makes sense.
forced disk -- makes sense.
So we have matrix of 7 possibilities, but only 4 make sense... IMO its confusing.
Pavel
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |