[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

passing options to modules loaded in initramfs



Hi,

After some discussion on IRC I was about to file a bug on the kernel,
but I'm still not convinced if that's appropiate, as there are various
ways to tackle this. So, please, give me your opinion on this.

I found that some very critical cmdline options for booting aren't
honoured anymore (I have an old computer that will exhibit various
problems because of incorrect dma detection with recent kernels). I
could finally dig that this is because drivers/ide/ide.c goes into a
module in default debian kernels, and modules don't read cmdline.

Now I found that the solution is very simple, adding the option as if
the module was loaded post-init and then running update-initramfs. But
I find this very non-obvious, and not very nice if you cannot boot.

I had to read kernel code to find out what source file was responsible
of this, to find that it is a module in Debian, then understanding
that initramfs just copies /etc/modules.d and uses it. Maybe I'm a
dummy, but I needed to do all that.

I couldn't find anywhere in the net something describing all this
process, but lots of references to the standard way of passing options
from grub/lilo.

To make things more confusing, when I installed, somehow I didn't have
DMA problems. I think I deducted from the isolinux help that I could
use ide-core.ide=nodma. A idiom that doesn't work with the installed
kernel+initramfs.

So, this could be handled by various ways:
- Putting notices in relevant places so that everybody can understand
what's happening (release notes, FAQs, package documentation..)
- Compiling with CONFIG_BLK_DEV_IDE=y (Ubuntu does this)
- Using Kyle McMartin's recent proposed patch [0] that enables modules
to read cmdline.
- Adding more intelligence to initramfs to detect this options and
pass them to the correct module (I think it already does this for a
couple of options), or using the same syntax as d-i (this seems easy
to add, although it differs from historic usage).

Thoughts?


[0] http://lkml.org/lkml/2007/4/18/212
--
Martín Ferrari

Reply to: