[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100503190136.GA4173@ucw.cz>
Date: Mon, 3 May 2010 21:01:36 +0200
From: Pavel Machek <pavel@....cz>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Arve Hj??nnev??g <arve@...roid.com>,
linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Alan Stern <stern@...land.harvard.edu>,
Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
Len Brown <len.brown@...el.com>,
Randy Dunlap <rdunlap@...otime.net>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Magnus Damm <damm@...l.co.jp>,
Nigel Cunningham <nigel@...onice.net>,
Cornelia Huck <cornelia.huck@...ibm.com>,
Ming Lei <tom.leiming@...il.com>,
Wu Fengguang <fengguang.wu@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Maxim Levitsky <maximlevitsky@...il.com>,
linux-doc@...r.kernel.org
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists