On Wednesday April 18, [email protected] wrote:
> > On Wed, 18 Apr 2007 11:55:52 -0400 Kyle McMartin <[email protected]> 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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
