Re: [PATCH] PM / sleep: add configurable delay for pm_test
From: Pavel Machek
Date: Sat Feb 21 2015 - 18:25:03 EST
On Sat 2015-02-21 14:56:01, Florian Fainelli wrote:
> 2015-02-21 12:32 GMT-08:00 Pavel Machek <pavel@xxxxxx>:
> >> Considering that Brian's change are enclosed within a CONFIG_PM_DEBUG
> >> ifdef, can we really use the code bloat as a technical argument here?
> > Yes.
> Help me understand a few things here:
What you are missing is that we try to keep _sources_ small and
> - if we need to turn on PM_DEBUG all the time, including mainline
> distributions, does that mean that:
> - portions of code existing only in PM_DEBUG should be
> moved out of it because it is actually useful outside of debug option?
> - CONFIG_PM itself is not self sufficient and there are
> still problems that require PM_DEBUG to be turned on?
> - should there be a second level debug option (e.g:
> CONFIG_PM_DEBUG_ADV) which gates specific control knobs like PM delay?
> The current 5 seconds delay is completely arbitrary and goes against
> the principle of not enforcing a policy, having this configurable
> brings this back in the mechanism principle.
5 second delay is arbitrary, and slightly ugly debugging hack, that is
acceptable because it is useful, small and unobtrusive. The second you
add 40 lines of sysfs glue.. it is no longer small and unobtrusive,
and no longer acceptable.
And yes, distros probably ship with PM_DEBUG on, and no, adding
another config option would not make the big & ugly hack more
OTOH if you added a hook to kprobes that alowed easy binary patching
of the value "5" while not adding 40 lines of overhead, that might be
Actually, you can probably pull the address from System.map and then
just write to it using /dev/mem, no? Just arrange for "5" to be in
variable that is in System.map.
And you also want to check the kernel parameters, they are modifiable
in runtime in at least same cases.
But we are not adding 40 lines of uglyness. Clear?
(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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/