the initial ramdisk, in a nutshell -- part 1

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

 



  for the purpose of summarizing how the initial ramdisk is processed
for a tutorial i'm writing, here's what i have so far -- feel free to
let me know if i'm way off-base anywhere.

  first, setting up the initial ramdisk is done chronologically based
on this chunk of include/linux/init.h:

...
#define core_initcall(fn)               __define_initcall("1",fn,1)
#define core_initcall_sync(fn)          __define_initcall("1s",fn,1s)
#define postcore_initcall(fn)           __define_initcall("2",fn,2)
#define postcore_initcall_sync(fn)      __define_initcall("2s",fn,2s)
#define arch_initcall(fn)               __define_initcall("3",fn,3)
#define arch_initcall_sync(fn)          __define_initcall("3s",fn,3s)
#define subsys_initcall(fn)             __define_initcall("4",fn,4)
#define subsys_initcall_sync(fn)        __define_initcall("4s",fn,4s)
#define fs_initcall(fn)                 __define_initcall("5",fn,5)
#define fs_initcall_sync(fn)            __define_initcall("5s",fn,5s)
#define rootfs_initcall(fn)             __define_initcall("rootfs",fn,rootfs)
#define device_initcall(fn)             __define_initcall("6",fn,6)
#define device_initcall_sync(fn)        __define_initcall("6s",fn,6s)
#define late_initcall(fn)               __define_initcall("7",fn,7)
#define late_initcall_sync(fn)          __define_initcall("7s",fn,7s)
...

  it's that rootfs_initcall() entry that entirely defines when the
initial ramdisk is established.

  next, whether or not you even build in support for an initial
ramdisk is configured by the Kconfig var CONFIG_BLK_DEV_INITRD in the
"General setup" menu, and that variable is used for the simple choice
in init/Makefile:

ifneq ($(CONFIG_BLK_DEV_INITRD),y)
obj-y                          += noinitramfs.o
else
obj-$(CONFIG_BLK_DEV_INITRD)   += initramfs.o
endif

  so if initrd support, you compile in initramfs.c.  otherwise,
compile in the much simpler noinitramfs.c.  and depending on which one
is selected, you register the appropriate rootfs_initcall() routine,
one of:

rootfs_initcall(default_rootfs);	# no initrd
rootfs_initcall(populate_rootfs);	# initrd

  so far, so good?  and, as i read it, if you select initrd support as
above, all you get is cpio-format initrd support.  if you additionally
want the older-style filesystem-format support, you additionally need
to select BLK_DEV_RAM, right?

  in any event, whatever is registered with rootfs_initcall() is
responsible for *completely* setting up the initrd.  the *real* root
filesystem is finally mounted later in init/main.c, with the call to
prepare_namespace().

  does all this look reasonable so far?

rday

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

--
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