[PATCH 0/2] [Maverick] kernel-maverick-upstart: pass entire command line to init

[Tim Gardner]

On 06/17/2010 03:46 AM, Andy Whitcroft wrote:
> As part of the blueprint kernel-maverick-upstart[1] we have been
> investigating passing all of the kernel command line to init.  This allows
> upstart to know everything that was passed so that we can share options,
> for example quiet.
>
> Below are sample options list as dumped by an additional debugging patch.
> In each case the orginal boot line is the same.  With the option disabled,
> ie. normal boot semantics:
>
>      [    0.000000] environ<BOOT_IMAGE=/boot/vmlinuz-2.6.34-4-generic>
>      [    0.000000] argument<splash>
>
> With the option enabled:
>
>      [    0.000000] environ<BOOT_IMAGE=/boot/vmlinuz-2.6.34-4-generic>
>      [    0.000000] environ<root=UUID=bb5209a0-aca5-49da-b99b-52eff65f986b>
>      [    0.000000] argument<ro>
>      [    0.000000] argument<quiet>
>      [    0.000000] argument<splash>
>
> Note that the semantics of init=foo<arg>  <arg>  ... are unchanged.
>
> The following patch set implements this for Maverick.  Proposing for
> Maverick.
>
> -apw
>
> [1] http://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-upstart
>
> Andy Whitcroft (2):
>    UBUNTU: SAUCE: add option to hand off all kernel parameters to init
>    UBUNTU: [Config] enable passing all kernel command line to init
>
>   debian.master/config/config.common.ubuntu |    1 +
>   include/linux/moduleparam.h               |    2 +-
>   init/Kconfig                              |    7 ++++++
>   init/main.c                               |   33 ++++++++++++++++++++++------
>   kernel/params.c                           |   20 ++++++++++++-----
>   5 files changed, 49 insertions(+), 14 deletions(-)
>
>

So this is likely an option I want disabled for the backports to Lucid, 
right?

There isn't a lot of information in the spec or your commit log about 
the real reason for this patch, other then its more convenient for 
upstart to have command line items pre-parsed. Is there a more 
fundamental reason?

rtg
-- 
Tim Gardner tim.gardner at canonical.com