Linux Virtualization - Aug 2016 - [PATCH 0904/1285] Replace numeric parameter like 0444 with macro

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 at intel.com>
Signed-off-by: Baole Ni <baolex.ni at intel.com>
---
 drivers/s390/virtio/virtio_ccw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c
index 8688ad4..56d3671 100644
--- a/drivers/s390/virtio/virtio_ccw.c
+++ b/drivers/s390/virtio/virtio_ccw.c
@@ -1074,7 +1074,7 @@ static unsigned long devs_no_auto[__MAX_SSID +
1][__DEV_WORDS];
 
 static char *no_auto = "";
 
-module_param(no_auto, charp, 0444);
+module_param(no_auto, charp, S_IRUSR | S_IRGRP | S_IROTH);
 MODULE_PARM_DESC(no_auto, "list of ccw bus id ranges not to be
auto-onlined");
 
 static int virtio_ccw_check_autoonline(struct ccw_device *cdev)
-- 
2.9.2

In general, I find sending 1285 patches to lkml unfriendly without doing a
precheck if the general idea is good.
This is especially true as you did NOT provide a cover letter that would
allow to hide this thread on lkml.


Regarding this particular patch, I do not really like this change, as I find
"0444" much easier to parse than "S_IRUSR | S_IRGRP |
S_IROTH"

Christian

On 08/02/2016 01:56 PM, 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.
> 
> Signed-off-by: Chuansheng Liu <chuansheng.liu at intel.com>
> Signed-off-by: Baole Ni <baolex.ni at intel.com>
> ---
>  drivers/s390/virtio/virtio_ccw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/s390/virtio/virtio_ccw.c
b/drivers/s390/virtio/virtio_ccw.c
> index 8688ad4..56d3671 100644
> --- a/drivers/s390/virtio/virtio_ccw.c
> +++ b/drivers/s390/virtio/virtio_ccw.c
> @@ -1074,7 +1074,7 @@ static unsigned long devs_no_auto[__MAX_SSID +
1][__DEV_WORDS];
> 
>  static char *no_auto = "";
> 
> -module_param(no_auto, charp, 0444);
> +module_param(no_auto, charp, S_IRUSR | S_IRGRP | S_IROTH);
>  MODULE_PARM_DESC(no_auto, "list of ccw bus id ranges not to be
auto-onlined");
> 
>  static int virtio_ccw_check_autoonline(struct ccw_device *cdev)
>

On Tue,  2 Aug 2016 19:56:46 +0800
Baole Ni <baolex.ni at intel.com> 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.
> 
> Signed-off-by: Chuansheng Liu <chuansheng.liu at intel.com>
> Signed-off-by: Baole Ni <baolex.ni at intel.com>
> ---
>  drivers/s390/virtio/virtio_ccw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/s390/virtio/virtio_ccw.c
b/drivers/s390/virtio/virtio_ccw.c
> index 8688ad4..56d3671 100644
> --- a/drivers/s390/virtio/virtio_ccw.c
> +++ b/drivers/s390/virtio/virtio_ccw.c
> @@ -1074,7 +1074,7 @@ static unsigned long devs_no_auto[__MAX_SSID +
1][__DEV_WORDS];
> 
>  static char *no_auto = "";
> 
> -module_param(no_auto, charp, 0444);
> +module_param(no_auto, charp, S_IRUSR | S_IRGRP | S_IROTH);
>  MODULE_PARM_DESC(no_auto, "list of ccw bus id ranges not to be
auto-onlined");
> 
>  static int virtio_ccw_check_autoonline(struct ccw_device *cdev)
NACK. I find 0444 more readable.

<And some general remarks: Your patches are lacking a proper component
prefix and have a rather long list of people on to: ...and sending
1000+ patches to lkml at once is not a very good idea either.>