> -----Original Message----- > From: Pavel Machek [mailto:pavel@xxxxxx] > Sent: Monday, February 01, 2010 5:49 AM > To: Rafael J. Wysocki > Cc: Leisner, Martin; linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > Subject: Re: syncing the disks when entering sleep > > > On Sunday 31 January 2010, Pavel Machek wrote: > > > On Wed 2010-01-27 21:46:43, Rafael J. Wysocki wrote: > > > > On Wednesday 27 January 2010, Pavel Machek wrote: > > > > > > > > > > > > Per-system property, which should better be > > > > > > > per-program-that-requires-suspend. You request suspend > without syncing > > > > > > > (you want it quick, battery is 90%), then the battery runs > low, and > > > > > > > system daeomn requests s2ram, not realizing that someone > disabled sync > > > > > > > from under him. > > > > > > > > > > > > I really prefer a per-system setting. The program that wants > to sync anyway > > > > > > can easily do that by itself. > > > > > > > > > > Yes, but existing apps do not know they have to sync. You are > > > > > essentially adding "break back compatibility" system wide > option, when > > > > > better alternative exists... See above for concrete example > where it > > > > > may hurt. > > > > > > > > I don't get what the problem is, really. > > > > > > > > There's _nothing_ here that breaks the existing behavior. If the > user doesn't > > > > set the switch, everything works as usual. If he does, breaking > the "back > > > > compatibility" is _his_ problem. > > > > > > So... you give them option to break back compatibility then blame it > > > on them.... Yes, we could do it, but it is not good. > > > > > > And better alternative exists, where you make the option per-suspend > > > so it does not have chance to break compatibility later. > > > > I'm not sure what you mean. Would you like it to reset itself during > resume > > or something like this? > > Yes, that or something similar would certainly help. > Pavel > -- So you're asking to give this knob "one shot behavior" (i.e. "then next sleep won't sync")? But I'm primarily interested in the behavior on embedded systems (where you control all the processes running -- there's no "user" involved. If a user starts messing with default settings, any unwanted behavior is the users problem (besides, this should only be writable as root). marty _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
