On Mon, Oct 20, 2014 at 03:04:36PM -0700, Andy Lutomirski wrote: > CONFIG_INIT_FALLBACK adds config bloat without an obvious use case > that makes it worth keeping around. Delete it. > > Signed-off-by: Andy Lutomirski <[email protected]> > --- > > Bring on the blame :)
Reviewed-by: Josh Triplett <[email protected]> Blame is easier to bear when shared. :) > init/Kconfig | 16 ---------------- > init/main.c | 5 ----- > 2 files changed, 21 deletions(-) > > diff --git a/init/Kconfig b/init/Kconfig > index ebbd5846478e..e84c6423a2e5 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1299,22 +1299,6 @@ source "usr/Kconfig" > > endif > > -config INIT_FALLBACK > - bool "Fall back to defaults if init= parameter is bad" > - default y > - help > - If enabled, the kernel will try the default init binaries if an > - explicit request from the init= parameter fails. > - > - This can have unexpected effects. For example, booting > - with init=/sbin/kiosk_app will run /sbin/init or even /bin/sh > - if /sbin/kiosk_app cannot be executed. > - > - The default value of Y is consistent with historical behavior. > - Selecting N is likely to be more appropriate for most uses, > - especially on kiosks and on kernels that are indended to be > - run under the control of a script. > - > config CC_OPTIMIZE_FOR_SIZE > bool "Optimize for size" > help > diff --git a/init/main.c b/init/main.c > index 2bd6105e5dc5..39dd52a3b78a 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -960,13 +960,8 @@ static int __ref kernel_init(void *unused) > ret = run_init_process(execute_command); > if (!ret) > return 0; > -#ifndef CONFIG_INIT_FALLBACK > panic("Requested init %s failed (error %d).", > execute_command, ret); > -#else > - pr_err("Failed to execute %s (error %d). Attempting > defaults...\n", > - execute_command, ret); > -#endif > } > if (!try_to_run_init_process("/sbin/init") || > !try_to_run_init_process("/etc/init") || > -- > 1.9.3 > -- 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/
