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@xxxxxxxxx>
Signed-off-by: Baole Ni <baolex.ni@xxxxxxxxx>
---
drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
index b52518c5..ba42aae 100644
--- a/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
+++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c
@@ -43,7 +43,7 @@
* >1 : specify number of partitions
*/
static int cpu_npartitions;
-module_param(cpu_npartitions, int, 0444);
+module_param(cpu_npartitions, int, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(cpu_npartitions, "# of CPU partitions");
/**
@@ -58,7 +58,7 @@ MODULE_PARM_DESC(cpu_npartitions, "# of CPU partitions");
* NB: If user specified cpu_pattern, cpu_npartitions will be ignored
*/
static char *cpu_pattern = "";
-module_param(cpu_pattern, charp, 0444);
+module_param(cpu_pattern, charp, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(cpu_pattern, "CPU partitions pattern");
struct cfs_cpt_data {
--
2.9.2
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
