Understanding mkinitcpio, kernel parameters, and hooks.

Question

I have a fairly complex setup involving dm-crypt volumes being unlocked pre-boot, so I'm somewhat familiar with mkinitcpio.conf and grub.cfg. However, I still have a burning question: are kernel parameters actually interpreted by the kernel? For example, the ip= parameter is included in the kernel documentation, leading me to believe that the kernel interprets this parameter and acts upon it during boot. On the other hand, the cryptdevice= parameter appears to be specific to the mkinitcpio encrypt hook (does not appear in kernel documentation) which interprets it and runs cryptsetup in early userspace. In this case, are kernel parameters simply being used as a vehicle in order to pass information from the boot loader to early userspace? If so, why couldn't this be done by including a configuration file directly in the initcpio, which could be parsed at boot-time? Such a configuration file seems like a superior means of passing information to early userspace, as different files could be used for different hooks, they could be of different formats (i.e. contain linebreaks), and would not be subject to the maximum kernel command line length.
In fact, it looks like some hooks already do this. For example, the sd-encrypt hook includes a file /etc/crypttab file directly in the initcpio image. Why would other hooks use kernel parameters when the early userspace filesystem is available for use?
I'm primarily asking just for educational purposes. Explanations are appreciated.

Answer 1

Spider.007 wrote:I think the ip-parameter is coincidentally the same as the net-module uses.
I found this in the mkinitcpio-nfs-utils ipconfig README:
These [parameters] (along with the ugliness of the long form) are present for compatibility with the in-kernel ipconfig code from 2.4 and earlier kernels.
which supports the hypothesis that the kernel parameter is left over from a time when network configurations were done in kernel-space. The syntax remained the same in the initcpio hook to maintain backwards comparability with older bootloader configurations. At least that's the impression I'm under.
Spider.007 wrote:The kernel is still responsible for mounting the rootfs; what has changed is that most distro's switched to initcpio's for reasons that are repeated on the wiki: ...
Yes, I believe the kernel itself performs the mount(2) which overwrites the / mountpoint with the real root filesystem after it is available. (But for all I know, a hook could be performing a mount(8) instead of the kernel!) What I meant was that the kernel no longer is responsible for all of the initializations necessary for the real root filesystem to become available (so the kernel can mount it), hence the need for initrd/initramfs/initcpio. Take dropbear_initrd_encrypt for example. Dropbear is a userspace SSH server. Without early userspace, an SSH server would have to be embedded in the kernel just for the 0.01% of users out there who need to be able to unlock volumes remotely. Early userspace allows complex systems like this (and other very different ones) to be configured without the need for patching the kernel.
I assume that some low-level kernel parameters (maxcpus= for example) are still relevant solely to the kernel, as things like SMP process scheduling can't easily be implemented in userspace.
Am I getting this right so far?
Last edited by EscapedNull (2015-01-13 19:40:50)