[PATCH] CONFIG_KMOD needs to be default y

[PATCH] CONFIG_KMOD needs to be default y

[Johannes Berg]

Far too many people configure their kernel without CONFIG_KMOD
and then complain that wireless breaks, thanks to Herbert Xu for
pointing me to this.

This patch makes CONFIG_KMOD default to "y" and adds a warning
that people should not turn it off.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Rusty Russell <rusty@rustcorp.com.au>
---
Maybe it should even depend on EMBEDDED? Who needs this option off
in the first place?

 init/Kconfig |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- everything.orig/init/Kconfig	2008-07-08 13:42:10.000000000 +0200
+++ everything/init/Kconfig	2008-07-08 13:43:41.000000000 +0200
@@ -895,6 +895,7 @@ config MODULE_SRCVERSION_ALL
 config KMOD
 	bool "Automatic kernel module loading"
 	depends on MODULES
+	default y
 	help
 	  Normally when you have selected some parts of the kernel to
 	  be created as kernel modules, you must load them (using the
@@ -902,7 +903,12 @@ config KMOD
 	  here, some parts of the kernel will be able to load modules
 	  automatically: when a part of the kernel needs a module, it
 	  runs modprobe with the appropriate arguments, thereby
-	  loading the module if it is available.  If unsure, say Y.
+	  loading the module if it is available.
+
+	  Do not say N unless you know you do not need it, and expect
+	  wireless, crypto and other things to break in this case.
+
+	  Say Y.
 
 config STOP_MACHINE
 	bool

Re: [PATCH] CONFIG_KMOD needs to be default y

[Christoph Hellwig]

On Tue, Jul 08, 2008 at 01:49:31PM +0200, Johannes Berg wrote:
> Far too many people configure their kernel without CONFIG_KMOD
> and then complain that wireless breaks, thanks to Herbert Xu for
> pointing me to this.
> 
> This patch makes CONFIG_KMOD default to "y" and adds a warning
> that people should not turn it off.

What about just killing the config option entirely?  It' basically
guarding a ~50 lines function + a sysctl variable.  I think having
modules but not CONFIG_KMOD is entirely unreasonable.

Re: [PATCH] CONFIG_KMOD needs to be default y

[Rusty Russell]

On Tuesday 08 July 2008 22:42:08 Christoph Hellwig wrote:
> On Tue, Jul 08, 2008 at 01:49:31PM +0200, Johannes Berg wrote:
> > Far too many people configure their kernel without CONFIG_KMOD
> > and then complain that wireless breaks, thanks to Herbert Xu for
> > pointing me to this.
> >
> > This patch makes CONFIG_KMOD default to "y" and adds a warning
> > that people should not turn it off.
>
> What about just killing the config option entirely?  It' basically
> guarding a ~50 lines function + a sysctl variable.  I think having
> modules but not CONFIG_KMOD is entirely unreasonable.

I agree with Christoph here.

But as a patch series please: it's spread pretty wide.  eg. first make it a 
non-prompting CONFIG option, then remove the users, then finally kill it.

Some existing request_module users might be able to use 
try_then_request_module, too...

Thanks!
Rusty.

Re: [PATCH] CONFIG_KMOD needs to be default y

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]

On Tue, 2008-07-08 at 23:03 +1000, Rusty Russell wrote:

> > What about just killing the config option entirely?  It' basically
> > guarding a ~50 lines function + a sysctl variable.  I think having
> > modules but not CONFIG_KMOD is entirely unreasonable.
> 
> I agree with Christoph here.

Yeah, like I said, I wasn't sure why it's there anyway.

> But as a patch series please: it's spread pretty wide.  eg. first make it a 
> non-prompting CONFIG option, then remove the users, then finally kill it.

Sure.

> Some existing request_module users might be able to use 
> try_then_request_module, too...

try_then_request_module seems buggy though. Or at least, doing something
unexpected. Here's the macro, for reference:

#define try_then_request_module(x, mod...) ((x) ?: (request_module(mod), (x)))

I think it should be
#define try_then_request_module(x, mod...) \
	((x) ?: ({request_module(mod); (x)}))

the difference being that it returns the result of the second "x" when
the first "x" fails. A potential user would be
net/bridge/netfilter/ebtables.c:

        ret = find_inlist_lock_noload(head, name, error, mutex);
        if (!ret) {
                request_module("%s%s", prefix, name);
                ret = find_inlist_lock_noload(head, name, error, mutex);
        }

which could then be written as

ret = try_then_request_module(
	find_inlist_lock_noload(head, name, error, mutex),
	"%s%s", prefix, name);

Also, in the case of MODULES=n, I think it should just be

static inline void printf_check(char *name, ...) __attribute__((format(printf, 1, 2))) {};
#define try_then_request_module(x, mod...) \
	({ printf_check(mod); (x) })

so (x) is only evaluated once.

A different variation you could make a case for is to not re-evaluate x
if request_module fails, which would then automatically collapse the
MODULES=n case:

#define try_then_request_module(x, mod...) \
	({ typeof(x) __ret = (x); __ret ?: \
		(request_module(mod) ? __r : (x)); })

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] CONFIG_KMOD needs to be default y

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

On Tue, 2008-07-08 at 18:06 +0200, Johannes Berg wrote:
> On Tue, 2008-07-08 at 23:03 +1000, Rusty Russell wrote:
> 
> > > What about just killing the config option entirely?  It' basically
> > > guarding a ~50 lines function + a sysctl variable.  I think having
> > > modules but not CONFIG_KMOD is entirely unreasonable.
> > 
> > I agree with Christoph here.
> 
> Yeah, like I said, I wasn't sure why it's there anyway.
> 
> > But as a patch series please: it's spread pretty wide.  eg. first make it a 
> > non-prompting CONFIG option, then remove the users, then finally kill it.
> 
> Sure.
> 
> > Some existing request_module users might be able to use 
> > try_then_request_module, too...
> 
> try_then_request_module seems buggy though. Or at least, doing something
> unexpected. Here's the macro, for reference:
> 
> #define try_then_request_module(x, mod...) ((x) ?: (request_module(mod), (x)))
> 
> I think it should be
> #define try_then_request_module(x, mod...) \
> 	((x) ?: ({request_module(mod); (x)}))
> 
> the difference being that it returns the result of the second "x" when
> the first "x" fails.

Never mind, it's not actually different, I just didn't understand that
syntax correctly.

The rest still stands though, do we really want to evaluate x twice when
CONFIG_MODULES is not set? Then, theoretically, the result shouldn't
change.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]