Skip to contentSkip to conversation

add kernel parameter to disable module load

PATCH In review Dave Young 2 participants 6 messages Jan 28, 2012 – Jan 31, 2012 Documentation

lore
Share & tools
lore

Dave Young

author
#0 lore raw

PATCH 1/1 add kernel parameter to disable module load

Sometimes we need to test a kernel of same version with code or config option changes.

We already have sysctl to disable module load, but add a kernel parameter will be more convenient.

---
 Documentation/kernel-parameters.txt |    2 ++
 kernel/module.c                     |    7 +++++++
 2 files changed, 9 insertions(+), 0 deletions(-)
Documentation/kernel-parameters.txt +2 -0
index e229769..b5cd482 100644
@@ -1796,6 +1796,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 	nomfgpt		[X86-32] Disable Multi-Function General Purpose
 			Timer usage (for AMD Geode machines).
 
+	nomodule	Disable module load
+
 	nopat		[X86] Disable PAT (page attribute table extension of
 			pagetables) support.
kernel/module.c +7 -0
index 178333c..72395f5 100644
@@ -3478,6 +3478,13 @@ void print_modules(void)
 	printk("\n");
 }
 
+static int __init module_load_disable(char *str)
+{
+	modules_disabled = 1;
+	return 1;
+}
+__setup("nomodule", module_load_disable);
+
 #ifdef CONFIG_MODVERSIONS
 /* Generate the signature for all relevant module structures here.
  * If these change, we don't want to try to parse the module. */
Signature · 1 line
1.7.4.4
#1 lore raw

kernel/module.c void print_modules(void) · line 3486

Quoted 13 lines · Dave Young

Sometimes we need to test a kernel of same version with code or config option changes.

We already have sysctl to disable module load, but add a kernel parameter will be more convenient.

kernel/module.c +6 -0
+static int __init module_load_disable(char *str)
+{
+	modules_disabled = 1;
+	return 1;
+}
+__setup("nomodule", module_load_disable);

You misspelled core_param here :)

Thanks,
Rusty.

author
#2 lore raw
Quoted 8 lines · Rusty Russell
Quoted 5 lines · Dave Young

Sometimes we need to test a kernel of same version with code or config option changes.

We already have sysctl to disable module load, but add a kernel parameter will be more convenient.

Quoted 8 lines

kernel/module.c void print_modules(void) · line 3486

Quoted 6 lines
kernel/module.c +6 -0
+static int __init module_load_disable(char *str)
+{
+	modules_disabled = 1;
+	return 1;
+}
+__setup("nomodule", module_load_disable);

You misspelled core_param here :)

Thanks for review, will update to use core_param

Signature · 2 lines
Thanks
Dave
author
#3 lore raw
In reply to Rusty Russell
Quoted 8 lines · Rusty Russell
Quoted 5 lines · Dave Young

Sometimes we need to test a kernel of same version with code or config option changes.

We already have sysctl to disable module load, but add a kernel parameter will be more convenient.

Quoted 9 lines

kernel/module.c void print_modules(void) · line 3486

Quoted 6 lines
kernel/module.c +6 -0
+static int __init module_load_disable(char *str)
+{
+	modules_disabled = 1;
+	return 1;
+}
+__setup("nomodule", module_load_disable);

You misspelled core_param here :)

Hello Rusty, If use core_param I'd better to change modules_disabled from int to bool or we must pass nomodule=1 instead of simply pass nomodule. But I think I can firstly post the core_param patch with current int type, then work on the transition patch for the variable type changes, what do you think?

Another do you think we need to expose this to sysfs via core_param? According to the sysctl code looks like we should not add sysfs interface to allow transition from "1" to "0"

Signature · 2 lines
Thanks
Dave
#4 lore raw
Quoted 21 lines · Dave Young
Quoted 8 lines · Rusty Russell
Quoted 5 lines · Dave Young

Sometimes we need to test a kernel of same version with code or config option changes.

We already have sysctl to disable module load, but add a kernel parameter will be more convenient.

Quoted 9 lines

kernel/module.c void print_modules(void) · line 3486

Quoted 6 lines
kernel/module.c +6 -0
+static int __init module_load_disable(char *str)
+{
+	modules_disabled = 1;
+	return 1;
+}
+__setup("nomodule", module_load_disable);

You misspelled core_param here :)

Quoted 5 lines

Hello Rusty, If use core_param I'd better to change modules_disabled from int to bool or we must pass nomodule=1 instead of simply pass nomodule. But I think I can firstly post the core_param patch with current int type, then work on the transition patch for the variable type changes, what do you think?

You could code your set function, but "bint" is what you want. Cleaning it up to be a bool is a good idea too.

Quoted 3 lines

Another do you think we need to expose this to sysfs via core_param? According to the sysctl code looks like we should not add sysfs interface to allow transition from "1" to "0"

If you want it writable, you definitely want to code your own set function so it's one way. But perm 0 or 0444 make sense, too.

Cheers,
Rusty.

author
#5 lore raw
Quoted 22 lines · Rusty Russell
Quoted 21 lines · Dave Young
Quoted 17 lines · Rusty Russell

kernel/module.c void print_modules(void) · line 3486

Quoted 13 lines · Dave Young

Sometimes we need to test a kernel of same version with code or config option changes.

We already have sysctl to disable module load, but add a kernel parameter will be more convenient.

kernel/module.c +6 -0
+static int __init module_load_disable(char *str)
+{
+	modules_disabled = 1;
+	return 1;
+}
+__setup("nomodule", module_load_disable);

You misspelled core_param here :)

Quoted 8 lines
Quoted 5 lines

Hello Rusty, If use core_param I'd better to change modules_disabled from int to bool or we must pass nomodule=1 instead of simply pass nomodule. But I think I can firstly post the core_param patch with current int type, then work on the transition patch for the variable type changes, what do you think?

You could code your set function, but "bint" is what you want. Cleaning it up to be a bool is a good idea too.

Thanks. I will try bint. Will consider to make it bool later because sysctl also need some changes.

Quoted 7 lines
Quoted 4 lines

Another do you think we need to expose this to sysfs via core_param? According to the sysctl code looks like we should not add sysfs interface to allow transition from "1" to "0"

If you want it writable, you definitely want to code your own set function so it's one way. But perm 0 or 0444 make sense, too.

I like 'perm 0' :)

Quoted 8 lines

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 2 lines
Thanks
Dave