2015-02-21 12:32 GMT-08:00 Pavel Machek <pa...@ucw.cz>:
>
>
>
>> 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:
- this particular change is enclosed within a debug option, so only
people interested in enabling PM_DEBUG will get access to it
- 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.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
