Re: [RFC PATCH 0/3 V2] Introduce usr_strtobool (previously kstrtobool)

[Jonathan Cameron <jic23@cam.ac.uk>]

If no one has any comments on this, who is likely to pick it up?
> Here is a second pass at introducing a new function to unify
> code that is attempting to get a boolean value from user input strings.
> 
> The first attempt (other than having some stupid bugs) was opposed by
> Alexy Dobriyan on the basis that it did completely insufficient checking
> on the string.  Given that under the original proposed name it was
> associated with the other kstrto* functions it was reasonable to assume
> if would be as strict as they are.  Hence the name change to remove
> an implication of this.
> 
> The use cases are both the pair below and the numerous boolean
> attributes in sysfs.  It's for these that I'm personally interested
> in having such a function, but as Greg pointed out a good starting
> point is to unify the places where this is already occuring.
> 
> The big questions to my mind are:
> 
> 1) Is the usr_strtobool name a good choice?
> 2) Should we introduce other acceptable boolean inputs?
>    Clearly there are issues in changing the list as it will at least
>    in theory change the two api's effected by this series.
> 
> Thanks,
> 
> Jonathan
> 
> Jonathan Cameron (3):
>   Add a usr_strtobool function matching semantics of existing in kernel
>     equivalents
>   debugfs: move to new usr_strtobool
>   params.c: Use new usr_strtobool function to process boolean inputs
> 
>  fs/debugfs/file.c      |   20 ++++++--------------
>  include/linux/string.h |    1 +
>  kernel/params.c        |   14 ++++----------
>  lib/string.c           |   29 +++++++++++++++++++++++++++++
>  4 files changed, 40 insertions(+), 24 deletions(-)
>