On Thu, Jun 30, 2022 at 3:06 AM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > On Wed, Jun 29, 2022 at 09:25:32PM -0700, Kalesh Singh wrote: > > Two concerns John raised: > > 1) Adding new ABI we need to maintain > > 2) 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
