separating initrd from initramfs: part 2

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

 



  a short followup to my earlier post on this topic.  if you look in
init/Kconfig, you read the section related to getting initrd/initramfs
support:

=====
config BLK_DEV_INITRD
        bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
        depends on BROKEN || !FRV
        help
          The initial RAM filesystem is a ramfs which is loaded by the
          boot loader (loadlin or lilo) and that is mounted as root
          before the normal boot procedure. It is typically used to
          load modules needed to mount the "real" root file system,
          etc. See <file:Documentation/initrd.txt> for details.

          If RAM disk support (BLK_DEV_RAM) is also included, this
          also enables initial RAM disk (initrd) support and adds
          15 Kbytes (more on some other architectures) to the kernel size.

          If unsure say Y.

if BLK_DEV_INITRD

source "usr/Kconfig"

endif
=====

  i'm thinking this could be more clearly presented since this option
*claims* to give you "initramfs/initrd" support but you have to read
the fine print to notice that you explicitly get initrd support only
if you *also* select BLK_DEV_RAM from drivers/block/Kconfig, which
describes itself thusly:

=====
config BLK_DEV_RAM
        tristate "RAM block device support"
        ---help---
          Saying Y here will allow you to use a portion of your RAM memory as
          a block device, so that you can make file systems on it,
          ... snip ...
          Most normal users won't need the RAM disk functionality, and can
          thus say N here.
=====

  in other words, the first option offers you initrd support, but you
get that only if you select BLK_DEV_RAM, an option which advertises
itself as not being necessary for most users.

  this is, i think, another good reason to separate initrd support
from initramfs support -- to avoid this confusion and possible
misinterpretation.

  you could select initramfs (which would probably be selected by most
folks), and if you *additionally* selected the (external) initrd
support, that might "select" BLK_DEV_RAM just to be on the safe side.

rday

p.s.  i think it's also tacky to read this in init/initramfs.c:

=====
static int __init populate_rootfs(void)
{
        char *err = unpack_to_rootfs(__initramfs_start,
                         __initramfs_end - __initramfs_start, 0);
        if (err)
                panic(err);
        if (initrd_start) {
#ifdef CONFIG_BLK_DEV_RAM
                int fd;
                printk(KERN_INFO "checking if image is initramfs...");
                err = unpack_to_rootfs((char *)initrd_start,
                        initrd_end - initrd_start, 1);
.....
=====

  the check "#ifdef CONFIG_BLK_DEV_RAM" is what is checking for initrd
support.  really, that's kind of misleading and tacky, and it would be
so much cleaner to have it check, say, "#ifdef CONFIG_INITRD_SUPPORT",
since you should have the right to ask for BLK_DEV_RAM support while
having no interest in an initrd whatever, no?

  more later.


========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux