possibly in aid of a future kernel newbie column, i'm trying to nail
down the logic of how initramfs/initrd works, so i plan on asking a
number of questions (some of them potentially dumb) just to make
*sure* i'm not missing any details, so let's start with a simple one.
throughout the kernel source tree, you can register routines to run
*very* early on in the boot process with a number of macros defined in
<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)
...
the fact that (on x86) that's the order that those routines will run
is shown in arch/x86/kernel/vmlinux.lds:
.initcall.init : AT(ADDR(.initcall.init) - 0xffffffff80000000) {
__initcall_start = .;
*(.initcallearly.init) __early_initcall_end = .; *(.initcall0.init)
*(.initcall0s.init) *(.initcall1.init) *(.initcall1s.init)
*(.initcall2.init) *(.initcall2s.init) *(.initcall3.init)
*(.initcall3s.init) *(.initcall4.init) *(.initcall4s.init)
*(.initcall5.init) *(.initcall5s.init) *(.initcallrootfs.init)
*(.initcall6.init) *(.initcall6s.init) *(.initcall7.init)
*(.initcall7s.init)
__initcall_end = .;
}
now, if you examine init/main.c, you can see where in the boot
process these routines will be invoked:
static void __init do_basic_setup(void)
{
rcu_init_sched(); /* needed by module_init stage. */
init_workqueues();
cpuset_init_smp();
usermodehelper_init();
driver_init();
init_irq_proc();
do_ctors();
do_initcalls(); <--- do all the initcalls
}
and just above that routine, you can see a loop that steps through
each initcall, invoking each one in that order:
static void __init do_initcalls(void)
{
initcall_t *call;
for (call = __early_initcall_end; call < __initcall_end; call++)
do_one_initcall(*call);
/* Make sure there is no pending stuff from the initcall sequence */
flush_scheduled_work();
}
so far, so good. now, AFAICT, the routine that's meant to process
the root filesystem is registered with rootfs_initcall(), in one of
two ways. at the bottom of init/initramfs.c, you can see:
rootfs_initcall(populate_rootfs);
while at the bottom of noinitramfs.c, you can seee:
rootfs_initcall(default_rootfs);
so the first trivial question -- regardless of how you've configured
your kernel or whether or not you've supplied your own initramfs, is
that point in the loop of processing initcalls when it gets to the
rootfs_initcall() routine the absolutely *first* place that *any*
checking is done as to how to proceed WRT what to use as a root
filesystem? am i asking this question clearly enough? thanks.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Linked In: http://www.linkedin.com/in/rpjday
Twitter: http://twitter.com/rpjday
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
