From: Ben Collins <ben.collins@ubuntu.com>
To: Kyle McMartin <kyle@canonical.com>
Cc: linux-kernel@vger.kernel.org, alan@redhat.com
Subject: Re: [RFC] [PATCH] Allow overriding module parameters from kernel command_line
Date: Wed, 18 Apr 2007 12:25:48 -0400 [thread overview]
Message-ID: <1176913548.6036.193.camel@cunning> (raw)
In-Reply-To: <20070418155552.GA3744@athena.road.mcmartin.ca>
On Wed, 2007-04-18 at 11:55 -0400, Kyle McMartin wrote:
> With the move to initramfs and heavily modular configs, which include
> loading storage drivers from early userspace, it's becoming harder
> to provide users with a way of overriding module parameters at boot.
>
> Currently, users would have to break into the initramfs, edit the
> modprobe options, and then let boot continue. They have a much easier time
> dealing with adding options on the command line from Grub or what have you.
>
> I hacked out this patch quickly to re-parse saved_command_line[] when we
> load a module in an attempt to rectify this.
>
> (The specific use-case I was looking at here was HPA commands failing on
> sata_nv controllers, and needing to pass the adma=0 option to the module...
> Users had a hard time testing without an easy way of overriding the module.)
>
> Clearly this is not entirely optimal, because we're parsing command_line
> after the module params are parsed. This ends of being a policy decision,
> whether the /sbin/modprobe commandline should override the kernel
> command_line, or vice versa.
>
> Anyway, please comment...
Just pasting my comments to kyle on IRC for benefit of discussion:
"I'm of the opinion that cmdline args from the kernel should override
modprobe args...mainly because adding those args to the kernel cmdline
is clearly an attempt to override userspace"
"maybe have some sysfs attr to disable this feature, so userspace can go
back to normal after whatever needed fixing"
The use case for us is that we've had to add a couple of initramfs
scripts to parse common module params (all_generic_ide for example).
We'd like to move away from this and have a clear way of passing any
module param on the kernel command line. Workarounds for users are much
easier than having to roll new CDs for every little quirk. Plus it's
easier for testing (if the quirk is a bug that keeps them from
installing at all, then we can't just hand them new kernels very
easily).
--
Ubuntu: http://www.ubuntu.com/
Linux1394: http://www.linux1394.org/
next prev parent reply other threads:[~2007-04-18 17:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-18 15:55 Kyle McMartin
2007-04-18 16:25 ` Ben Collins [this message]
2007-04-18 21:45 ` Andrew Morton
2007-04-18 22:47 ` Neil Brown
2007-04-18 22:58 ` mkinitrd. (was Re: [RFC] [PATCH] Allow overriding module parameters from kernel command_line) Dave Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1176913548.6036.193.camel@cunning \
--to=ben.collins@ubuntu.com \
--cc=alan@redhat.com \
--cc=kyle@canonical.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome