On Thu, Jun 30, 2022 at 3:06 AM Jason A. Donenfeld Jason@zx2c4.com wrote:
On Wed, Jun 29, 2022 at 09:25:32PM -0700, Kalesh Singh wrote:
Two concerns John raised:
- Adding new ABI we need to maintain
- Having unclear config options
Another idea, I think, is to add the Kconfig option as CONFIG_SUSPEND_SKIP_RNG_RESEED? Similar to existing CONFIG_SUSPEND_SKIP_SYNC and I think it would address those concerns.
I mentioned in my reply to him that this doesn't really work for me:
| As a general rule, I don't expose knobs like that in wireguard /itself/, | but wireguard has no problem with adapting to whatever machine properties | it finds itself on. And besides, this *is* a very definite device | property, something really particular and peculiar about the machine | the kernel is running on. It's a concrete thing that the kernel should | know about. So let's go with your "very clear description idea", above, | instead.
IOW, we're not going to add a tunable on every possible place this is used.
Hrm. Can you explain a bit more on why you're particularly adamant against scoping the config to describe the behavior we want from the kernel rather than describing a "machine property"? As personally, I greatly prefer Kalesh's suggestion (as it avoids the same critique one could make of the CONFIG_ANDROID "flag"), but admittedly this is bikeshed territory.
Does this preference come out of the too-many-options-in-gpg antipattern? Or is there something else?
Anyway if you don't want a runtime switch, make a compiletime switch called CONFIG_PM_CONTINUOUS_RAPID_AUTOSLEEPING or whatever, write some very discouraging help text, and call it a day. And this way you don't have to worry about ABI and we can change this later on and do the whole thing as a no-big-deal change that somebody can tweak later without issue.
Yeah, this is ok with me, as I don't see much benefit to creating a userland ABI, as I don't think at this point we expect the behavior to shift or oscillate at runtime.
thanks -john