mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kyle McMartin <kyle@canonical.com>,
	linux-kernel@vger.kernel.org, alan@redhat.com,
	bcollins@ubuntu.com
Subject: Re: [RFC] [PATCH] Allow overriding module parameters from kernel command_line
Date: Thu, 19 Apr 2007 08:47:13 +1000	[thread overview]
Message-ID: <17958.40945.937891.44930@notabene.brown> (raw)
In-Reply-To: message from Andrew Morton on Wednesday April 18

On Wednesday April 18, akpm@linux-foundation.org wrote:
> > On Wed, 18 Apr 2007 11:55:52 -0400 Kyle McMartin <kyle@canonical.com> 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.
> 
> Similar-but-different: I was trying to persuade a Fedora system to use ext2
> for the root filesystem the other day.  Turns out that we somehow managed
> to break `rootfstype=' in this situation and it cheerfully continued to use
> ext3.
> 
> Fixed by changing /etc/fstab and rebuilding initrd, but IMO rootfstype=
> should have worked.

I think these are both issues that should be solved by smarts in the
initrd.

All of the (unused) kernel parameters are in the environment aren't
they? (if not, they can easily be put there).

So maybe insmod/modprobe could be updated to extract relevant options
from the environment.
And the mount of the root filesystem should be called as:

    mount ${rootfstype+-t $rootfstype} $dev $mountpoint

We are depending more and more on initrd and I think it hurts not
having a reference implementation.
Currently each distro makes their own and while I'm sure they are all
quite good in their own way, the fact that they are independent makes
community input harder.

What we really need is a single reference implementation of "mkinitrd"
which each distro can fiddle with to their heart's content.  Then
sensible ideas like the above can be incorporated into the reference,
and all distros will ultimately pick them up.

But unfortunately I don't have the time to volunteer for this role...

NeilBrown

  reply	other threads:[~2007-04-18 22:47 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
2007-04-18 21:45 ` Andrew Morton
2007-04-18 22:47   ` Neil Brown [this message]
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=17958.40945.937891.44930@notabene.brown \
    --to=neilb@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@redhat.com \
    --cc=bcollins@ubuntu.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