[PATCH 0032/1285] Replace numeric parameter like 0444 with macro

[PATCH 0032/1285] Replace numeric parameter like 0444 with macro

[Baole Ni]

I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.

Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
 arch/x86/kernel/cpu/mcheck/mce.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 92e5e37..95b3028 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -2345,10 +2345,10 @@ static ssize_t store_int_with_restart(struct device *s,
 	return ret;
 }
 
-static DEVICE_ATTR(trigger, 0644, show_trigger, set_trigger);
-static DEVICE_INT_ATTR(tolerant, 0644, mca_cfg.tolerant);
-static DEVICE_INT_ATTR(monarch_timeout, 0644, mca_cfg.monarch_timeout);
-static DEVICE_BOOL_ATTR(dont_log_ce, 0644, mca_cfg.dont_log_ce);
+static DEVICE_ATTR(trigger, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, show_trigger, set_trigger);
+static DEVICE_INT_ATTR(tolerant, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, mca_cfg.tolerant);
+static DEVICE_INT_ATTR(monarch_timeout, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, mca_cfg.monarch_timeout);
+static DEVICE_BOOL_ATTR(dont_log_ce, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, mca_cfg.dont_log_ce);
 
 static struct dev_ext_attribute dev_attr_check_interval = {
 	__ATTR(check_interval, 0644, device_show_int, store_int_with_restart),
-- 
2.9.2

Re: [PATCH 0032/1285] Replace numeric parameter like 0444 with macro

[Borislav Petkov]

First of all,

what is that flood of patches and why am I on CC on so many, even if I
don't have anything to do with the code most of them touch? Have you
heard of get_maintainer.pl?

Then, I'd never do all that "work" that if I were you.

Then, your patch Subject is the *same* on every patch. Not good.

Ditto for the commit message but I guess one can do only so many
variations of the same thing.

On Tue, Aug 02, 2016 at 06:35:51PM +0800, Baole Ni wrote:
> I find that the developers often just specified the numeric value
> when calling a macro which is defined with a parameter for access permission.
> As we know, these numeric value for access permission have had the corresponding macro,
> and that using macro can improve the robustness and readability of the code,
> thus, I suggest replacing the numeric parameter with the macro.

I don't think this is a valid argument - I can understand 0644 much
faster than the macros but maybe this is just me...

> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> Signed-off-by: Baole Ni <baolex.ni@intel.com>

This SOB chain is wrong. Why are there two people doing a trivial patch?

> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
> index 92e5e37..95b3028 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -2345,10 +2345,10 @@ static ssize_t store_int_with_restart(struct device *s,
>  	return ret;
>  }
>  
> -static DEVICE_ATTR(trigger, 0644, show_trigger, set_trigger);
> -static DEVICE_INT_ATTR(tolerant, 0644, mca_cfg.tolerant);
> -static DEVICE_INT_ATTR(monarch_timeout, 0644, mca_cfg.monarch_timeout);
> -static DEVICE_BOOL_ATTR(dont_log_ce, 0644, mca_cfg.dont_log_ce);
> +static DEVICE_ATTR(trigger, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, show_trigger, set_trigger);
> +static DEVICE_INT_ATTR(tolerant, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, mca_cfg.tolerant);
> +static DEVICE_INT_ATTR(monarch_timeout, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, mca_cfg.monarch_timeout);
> +static DEVICE_BOOL_ATTR(dont_log_ce, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, mca_cfg.dont_log_ce);

So no, I won't take this senseless churn - it doesn't fix or improve
anything IMO.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--