On Tue, Jul 06, 2021 at 01:06:19AM +0000, Krzysztof Wilczyński wrote: > A common use case for many PCI sysfs objects is to either enable some > functionality or trigger an action following a write to a given > attribute where the value is written would be simply either "1" or "0" > synonymous with either disabling or enabling something. > > Parsing and validation of the input values are currently done using the > kstrtoul() function to convert anything in the string buffer into an > integer value - anything non-zero would be accepted as "enable" and zero > simply as "disable". > > For a while now, the kernel offers another function called kstrtobool() > which was created to parse common user inputs into a boolean value, so > that a range of values such as "y", "n", "1", "0", "on" and "off" > handled in a case-insensitive manner would yield a boolean true or false > result accordingly after the input string has been parsed. > > Thus, move to kstrtobool() over kstrtoul() as it's a better fit for > parsing user input, and it also implicitly offers a range check as only > a finite amount of possible input values will be considered as valid. If I understand correctly, a user could enable things by writing "5" today, and if we switch to kstrbool(), that will no longer work. I'm sure everything is *documented* such that one should write "1" or other sensible values. But I'm not sure there's benefit in adding new restrictions. Bjorn
