Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, 2022-01-19 at 16:00 -0500, Steven Rostedt wrote: > On Wed, 19 Jan 2022 21:25:08 +0200 > Andy Shevchenko wrote: > > > > I say keep it one line! > > > > > > Reviewed-by: Steven Rostedt (Google) > > > > I believe Sakari strongly follows the 80 rule, which means... > > Checkpatch says "100" I think we need to simply update the docs (the > documentation always lags the code ;-) checkpatch doesn't say anything normally, it's a stupid script. It just mindlessly bleats a message when a line exceeds 100 chars... Just fyi: I think it's nicer on a single line too.
RE: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
> > except '"no\0\0yes" + v * 4' works a bit better. > > Is it a C code obfuscation contest? That would be: return &(v * 3)["no\0yes"]; :-) - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, Jan 19, 2022 at 04:00:17PM -0500, Steven Rostedt wrote: > On Wed, 19 Jan 2022 21:25:08 +0200 > Andy Shevchenko wrote: > > > > I say keep it one line! > > > > > > Reviewed-by: Steven Rostedt (Google) > > > > I believe Sakari strongly follows the 80 rule, which means... > > Checkpatch says "100" I think we need to simply update the docs (the > documentation always lags the code ;-) The idea of checkpatch change is for old code to avoid tons of patches to satisfy 80 rule in (mostly) staging code. Some maintainers started / have been using relaxed approach. -- With Best Regards, Andy Shevchenko
Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, 19 Jan 2022 21:25:08 +0200 Andy Shevchenko wrote: > > I say keep it one line! > > > > Reviewed-by: Steven Rostedt (Google) > > I believe Sakari strongly follows the 80 rule, which means... Checkpatch says "100" I think we need to simply update the docs (the documentation always lags the code ;-) bdc48fa11e46f -- Steve
Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, 19 Jan 2022 21:22:57 +0200 Andy Shevchenko wrote: > On Wed, Jan 19, 2022 at 04:38:26PM +, David Laight wrote: > > > > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; > > > > > > } > > > > > > return "yes\0no" + v * 4; > > > > > > :-) > > > > except '"no\0\0yes" + v * 4' works a bit better. > > Is it a C code obfuscation contest? > return '/'/'/'; -- Steve
Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, Jan 19, 2022 at 04:38:26PM +, David Laight wrote: > > > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; } > > > > return "yes\0no" + v * 4; > > > > :-) > > except '"no\0\0yes" + v * 4' works a bit better. Is it a C code obfuscation contest? -- With Best Regards, Andy Shevchenko
Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, Jan 19, 2022 at 10:06:35AM -0500, Steven Rostedt wrote: > On Wed, 19 Jan 2022 11:18:59 +0200 > Sakari Ailus wrote: > > On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote: > > > @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct > > > tomoyo_io_buffer *head, > > > case 3: > > > if (cond->grant_log != TOMOYO_GRANTLOG_AUTO) > > > tomoyo_io_printf(head, " grant_log=%s", > > > - tomoyo_yesno(cond->grant_log == > > > - TOMOYO_GRANTLOG_YES)); > > > + yesno(cond->grant_log == > > > TOMOYO_GRANTLOG_YES)); > > > > This would be better split on two lines. > > Really? Yuck! > > I thought the "max line size" guideline was going to grow to a 100, but I > still see it as 80. But anyway... > > cond->grant_log == > TOMOYO_GRANTLOG_YES > > is not readable at all. Not compared to > > cond->grant_log == TOMOYO_GRANTLOG_YES > > I say keep it one line! > > Reviewed-by: Steven Rostedt (Google) I believe Sakari strongly follows the 80 rule, which means... > > Reviewed-by: Sakari Ailus ...chose either of these tags and be happy with :-) -- With Best Regards, Andy Shevchenko
RE: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
> > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; } > > return "yes\0no" + v * 4; > > :-) except '"no\0\0yes" + v * 4' works a bit better. - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
RE: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
> > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; } return "yes\0no" + v * 4; :-) - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, 19 Jan 2022 11:18:59 +0200 Sakari Ailus wrote: > On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote: > > @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct > > tomoyo_io_buffer *head, > > case 3: > > if (cond->grant_log != TOMOYO_GRANTLOG_AUTO) > > tomoyo_io_printf(head, " grant_log=%s", > > -tomoyo_yesno(cond->grant_log == > > - TOMOYO_GRANTLOG_YES)); > > +yesno(cond->grant_log == > > TOMOYO_GRANTLOG_YES)); > > This would be better split on two lines. Really? Yuck! I thought the "max line size" guideline was going to grow to a 100, but I still see it as 80. But anyway... cond->grant_log == TOMOYO_GRANTLOG_YES is not readable at all. Not compared to cond->grant_log == TOMOYO_GRANTLOG_YES I say keep it one line! Reviewed-by: Steven Rostedt (Google) -- Steve > > Then, > > Reviewed-by: Sakari Ailus
Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wed, 19 Jan 2022 11:15:08 +0200 Andy Shevchenko wrote: > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; } > > > > Perhaps keep it on 4 lines? Yes, yes/no is short, but if we add others > (enable/disable) it will not be possible to keep on one line. And hence > style will be broken among similar functions. Agreed. Functions should always be of the normal format: type func(params) { body; } Unless it is a stub function. type func(params) { return 0; } -- Steve
Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
Hi Lucas, On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote: > @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct > tomoyo_io_buffer *head, > case 3: > if (cond->grant_log != TOMOYO_GRANTLOG_AUTO) > tomoyo_io_printf(head, " grant_log=%s", > - tomoyo_yesno(cond->grant_log == > - TOMOYO_GRANTLOG_YES)); > + yesno(cond->grant_log == > TOMOYO_GRANTLOG_YES)); This would be better split on two lines. Then, Reviewed-by: Sakari Ailus -- Sakari Ailus
Re: [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation
On Wednesday, January 19, 2022, Lucas De Marchi wrote: > There are a few implementations of yesno() in the tree. Consolidate them > in include/linux/string_helpers.h. Quite a few users of open coded > yesno() could later be converted to the new function: > > $ git grep '?\s*"yes"\s*' | wc -l > 286 > $ git grep '?\s*"no"\s*' | wc -l > 20 > > The inlined function should keep the const strings local to each > compilation unit, the same way it's now, thus not changing the current > behavior. > > Signed-off-by: Lucas De Marchi > --- > .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 6 +- > drivers/gpu/drm/i915/i915_utils.h | 5 - > .../net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 11 --- > include/linux/string_helpers.h | 2 ++ > security/tomoyo/audit.c| 2 +- > security/tomoyo/common.c | 18 -- > security/tomoyo/common.h | 1 - > 7 files changed, 8 insertions(+), 37 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c > index 9d43ecb1f692..b59760f91bf6 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c > @@ -23,6 +23,7 @@ > * > */ > > +#include > #include > > #include "dc.h" > @@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry { > uint32_t param1; > }; > > -static inline const char *yesno(bool v) > -{ > - return v ? "yes" : "no"; > -} > - > /* parse_write_buffer_into_params - Helper function to parse debugfs > write buffer into an array > * > * Function takes in attributes passed to debugfs write entry > diff --git a/drivers/gpu/drm/i915/i915_utils.h > b/drivers/gpu/drm/i915/i915_utils.h > index 7a5925072466..2a8781cc648b 100644 > --- a/drivers/gpu/drm/i915/i915_utils.h > +++ b/drivers/gpu/drm/i915/i915_utils.h > @@ -414,11 +414,6 @@ wait_remaining_ms_from_jiffies(unsigned long > timestamp_jiffies, int to_wait_ms) > #define MBps(x) KBps(1000 * (x)) > #define GBps(x) ((u64)1000 * MBps((x))) > > -static inline const char *yesno(bool v) > -{ > - return v ? "yes" : "no"; > -} > - > static inline const char *onoff(bool v) > { > return v ? "on" : "off"; > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c > b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c > index 7d49fd4edc9e..61a04d7abc1f 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c > @@ -2015,17 +2015,6 @@ static const struct file_operations > rss_debugfs_fops = { > /* RSS Configuration. > */ > > -/* Small utility function to return the strings "yes" or "no" if the > supplied > - * argument is non-zero. > - */ > -static const char *yesno(int x) > -{ > - static const char *yes = "yes"; > - static const char *no = "no"; > - > - return x ? yes : no; > -} > - > static int rss_config_show(struct seq_file *seq, void *v) > { > struct adapter *adapter = seq->private; > diff --git a/include/linux/string_helpers.h b/include/linux/string_ > helpers.h > index 4ba39e1403b2..e980dec05d31 100644 > --- a/include/linux/string_helpers.h > +++ b/include/linux/string_helpers.h > @@ -102,4 +102,6 @@ char *kstrdup_quotable_file(struct file *file, gfp_t > gfp); > > void kfree_strarray(char **array, size_t n); > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; } Perhaps keep it on 4 lines? Yes, yes/no is short, but if we add others (enable/disable) it will not be possible to keep on one line. And hence style will be broken among similar functions. Also it needs to be rebased and resend after -rc1, I expect conflict here. > + > #endif > diff --git a/security/tomoyo/audit.c b/security/tomoyo/audit.c > index d79bf07e16be..1458e27361e8 100644 > --- a/security/tomoyo/audit.c > +++ b/security/tomoyo/audit.c > @@ -166,7 +166,7 @@ static char *tomoyo_print_header(struct > tomoyo_request_info *r) >"#%04u/%02u/%02u %02u:%02u:%02u# profile=%u mode=%s > granted=%s (global-pid=%u) task={ pid=%u ppid=%u uid=%u gid=%u euid=%u > egid=%u suid=%u sgid=%u fsuid=%u fsgid=%u }", >stamp.year, stamp.month, stamp.day, stamp.hour, >stamp.min, stamp.sec, r->profile, > tomoyo_mode[r->mode], > - tomoyo_yesno(r->granted), gpid, tomoyo_sys_getpid(), > + yesno(r->granted), gpid, tomoyo_sys_getpid(), >tomoyo_sys_getppid(), >from_kuid(&init_user_ns, current_uid()), >from_kgid(&init_user_ns, current_gid()), > diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c > index 5c64927bf2b3..304ed0f426dd 100644 > --- a/security/tomoyo/common.c > +++ b/security/tomoyo/common.c > @@ -8,6 +8,7 @@ > #include > #inclu