i started this discussion over on the embedded linux list, but it
would seem to be more appropriate here so i'll start over, and i'll
report back to the embedded list what the results are.
in short, i want to know if it's possible to separate the config
selections of INITRD and INITRAMFS so you can choose them
independently. more specifically, i want to know if one can select
(internal) INITRAMFS support without having to select (external)
INITRD support, since many embedded systems find it handy to boot from
that internal initramfs image, but may have no need whatsoever to
support an external (what we've known historically as) initrd image.
and leaving out initrd support looks like it might save some bytes.
with me so far?
just to clarify the terminology, an "initrd" image would be an
independent cpio-format image that you'd pass via, for example, grub,
as in:
title Fedora (2.6.25.11-97.fc9.i686)
root (hd0,0)
kernel /vmlinuz-2.6.25.11-97.fc9.i686 ... etc etc ...
initrd /initrd-2.6.25.11-97.fc9.i686.img <--- that
while "initramfs" refers, of course, to the internal cpio-format image
that you can build directly into the kernel image (see the contents of
the top-level usr/ directory in the kernel source tree for the code
that does that).
at the moment, you can select support for both or neither, as seen
in init/Kconfig:
=====
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
=====
see how that works? the (IMHO, badly-named) config option
BLK_DEV_INITRD is what selects either both features, or neither of
them -- you have no freedom to pick *only* initramfs support. does
all this make sense so far?
now, let's summarize from where these images are obtained at boot
time, and i'm fairly sure i know this part, but feel free to correct
me if i'm wrong. (and let's stick with 32-bit x86 for the time being
-- i'm hoping this generalizes to non-x86 arches without much pain.)
the external initrd image (if one is supplied) is identified in
include/asm-x86/bootparam.h thusly:
=====
struct setup_header {
... snip ...
__u32 ramdisk_image;
__u32 ramdisk_size;
... snip ...
=====
and those values are processed in arch/x86/kernel/setup.c. so far,
so good with the initrd image?
the initramfs image, on the other hand, is
identified in arch/x86/kernel/vmlinux_32.lds.S:
======
#if defined(CONFIG_BLK_DEV_INITRD)
. = ALIGN(PAGE_SIZE);
.init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
__initramfs_start = .;
*(.init.ramfs)
__initramfs_end = .;
}
#endif
=====
so as long as you selected BLK_DEV_INITRD, the internal initramfs
image is completely specified by __initramfs_start and
__initramfs_end.
i'll stop now and let folks correct anything before heading on to
part 2.
rday
--
========================================================================
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
