Subject: Re: [PATCH 0/3] lib/string_helpers: Add a few string helpers

From: Jani Nikula <[email-masked]>
Date: Wed, 19 Jan 2022 10:02:31 +0200

On Tue, 18 Jan 2022, Lucas De Marchi <[email-masked]> wrote:
> Add some helpers under lib/string_helpers.h so they can be used
> throughout the kernel. When I started doing this there were 2 other
> previous attempts I know of, not counting the iterations each of them
> had:
>
> 1) https://lore.kernel.org/all/[email-masked]/
> 2) https://lore.kernel.org/all/[email-masked]/#t
>
> Going through the comments I tried to find some common ground and
> justification for what is in here, addressing some of the concerns
> raised.
>
> a. This version should be a drop-in replacement for what is currently in
>    the tree, with no change in behavior or binary size. For binary
>    size what I checked wat that the linked objects in the end have the
>    same size (gcc 11). From comments in the previous attempts this seems
>    also the case for earlier compiler versions
>
> b. I didn't change the function name to choice_* as suggested by Andrew
>    Morton in [email-masked]
>    because other people argumented in favor of shorter names for these
>    simple helpers - if they are long and people simply not use due to
>    that, we failed
>
> c. Use string_helper.h for these helpers - pulling string.h in the
>    compilations units was one of the concerns and I think re-using this
>    already existing header is better than creating a new string-choice.h
>
> d. This doesn't bring onoff() helper as there are some places in the
>    kernel with onoff as variable - another name is probably needed for
>    this function in order not to shadow the variable, or those variables
>    could be renamed.  Or if people wanting  <someprefix>
>    try to find a short one
>
> e. One alternative to all of this suggested by Christian König
>    ([email-masked]) would be to add a
>    printk format. But besides the comment, he also seemed to like
>    the common function. This brought the argument from others that the
>    simple yesno()/enabledisable() already used in the code is easier to
>    remember and use than e.g. %py[DOY]
>
> Last patch also has some additional conversion of open coded cases. I
> preferred starting with drm/ since this is "closer to home".
>
> I hope this is a good summary of the previous attempts and a way we can
> move forward.

Thanks for picking this up again. I agree with the approach here.

Acked-by: Jani Nikula <[email-masked]>

>
> Andrew Morton, Petr Mladek, Andy Shevchenko: if this is accepted, my
> proposal is to take first 2 patches either through mm tree or maybe
> vsprintf. Last patch can be taken later through drm.
>
> thanks
> Lucas De Marchi
>
> Cc: Alex Deucher <[email-masked]>
> Cc: Andrew Morton <[email-masked]>
> Cc: Andy Shevchenko <[email-masked]>
> Cc: Andy Shevchenko <[email-masked]>
> Cc: Ben Skeggs <[email-masked]>
> Cc: Christian König <[email-masked]>
> Cc: Chris Wilson <[email-masked]>
> Cc: Daniel Vetter <[email-masked]>
> Cc: David Airlie <[email-masked]>
> Cc: David S. Miller <[email-masked]>
> Cc: Emma Anholt <[email-masked]>
> Cc: Eryk Brol <[email-masked]>
> Cc: Francis Laniel <[email-masked]>
> Cc: Greg Kroah-Hartman <[email-masked]>
> Cc: Harry Wentland <[email-masked]>
> Cc: Jakub Kicinski <[email-masked]>
> Cc: Jani Nikula <[email-masked]>
> Cc: Joonas Lahtinen <[email-masked]>
> Cc: Julia Lawall <[email-masked]>
> Cc: Kentaro Takeda <[email-masked]>
> Cc: Leo Li <[email-masked]>
> Cc: Mikita Lipski <[email-masked]>
> Cc: Petr Mladek <[email-masked]>
> Cc: Rahul Lakkireddy <[email-masked]>
> Cc: Raju Rangoju <[email-masked]>
> Cc: Rasmus Villemoes <[email-masked]>
> Cc: Rodrigo Vivi <[email-masked]>
> Cc: Sakari Ailus <[email-masked]>
> Cc: Sergey Senozhatsky <[email-masked]>
> Cc: Steven Rostedt <[email-masked]>
> Cc: Vishal Kulkarni <[email-masked]>
>
> Lucas De Marchi (3):
>   lib/string_helpers: Consolidate yesno() implementation
>   lib/string_helpers: Add helpers for enable[d]/disable[d]
>   drm: Convert open yes/no strings to yesno()
>
>  drivers/gpu/drm/amd/amdgpu/atom.c              |  3 ++-
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  |  6 +-----
>  drivers/gpu/drm/drm_client_modeset.c           |  3 ++-
>  drivers/gpu/drm/drm_dp_helper.c                |  3 ++-
>  drivers/gpu/drm/drm_gem.c                      |  3 ++-
>  drivers/gpu/drm/i915/i915_utils.h              | 15 ---------------
>  drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c  |  4 +++-
>  drivers/gpu/drm/radeon/atom.c                  |  3 ++-
>  drivers/gpu/drm/v3d/v3d_debugfs.c              | 11 ++++++-----
>  drivers/gpu/drm/virtio/virtgpu_debugfs.c       |  3 ++-
>  .../net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 11 -----------
>  include/linux/string_helpers.h                 |  4 ++++
>  security/tomoyo/audit.c                        |  2 +-
>  security/tomoyo/common.c                       | 18 ++++--------------
>  security/tomoyo/common.h                       |  1 -
>  15 files changed, 31 insertions(+), 59 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center