Hi. Pavel Machek wrote: > On Tue 2010-02-02 07:55:04, Nigel Cunningham wrote: >> Pavel Machek wrote: >>>> 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. >> No, that would only make things more confusing. What other kernel knob >> turns itself off like that? Even drop caches, which might be reasonably >> expected to do so, doesn't. > > IIRC drop caches only drops once... Yes. It drops them when you set the value non zero (value is a bitflag saying what to drop). To do the same thing again, you need to set it to some other value then to the value you want. > Fine, that simply shows that we should not have the knob. Rather, > suspend should be getting parameters; one of them is suspend type (S1, > mem, disk), second is test mode (full, only drivers, only core, ...), > next is whether to sync or not... > > Maybe we really want sys_suspend() syscall. I don't see why it shows that we should not have the knob, or rather, why you're now arguing that the knob should exist, but be hidden in a binary only interface. It seems illogical. Regards, Nigel _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
