Halil Pasic <pasic@linux.ibm.com> writes:
On Thu, 15 Jan 2026 08:28:51 +0100 Markus Armbruster <armbru@redhat.com> wrote:
I understand that you're mirroring how @poll-grow and @poll-shrink work, but let's ignore that for a minute.
Compare four possible interfaces:
1. Optional @poll-weight defaults to 2. Values <= 0 are rejected.
2. Optional @poll-weight defaults to 2. Value 0 is replaced by the default value 2. Values < 0 are rejected.
3. Optional @poll-weight defaults to 0. Values < 0 are rejected. Value 0 makes the system pick a value, namely 2.
4. Optional @poll-weight defaults to 0. Values < 0 are rejected. Value 0 makes the system pick a value. It currently picks 2.
The difference between 3. and 4. is that 3. makes "system picks 2" part of the contract, while 4. doesn't.
1. is the simplest. Is 2.'s additional complexity worthwhile? 3.'s? 4.'s?
Isn't there more options? Like
Yes :)
5. Optional @poll-weight defaults to system-default. Value 0 is replaced by the system pick the system default value. Currently the system default value is 2. Values < 0 are rejected.
That would mean: * current value inspectable * system default not part of the interface contract * interface offers a "please go back to value not user specified: operation
BTW I like your approach with explicitly listing and evaluating the options a lot!
Thanks!