Hi Robert,
El Mon, Aug 04, 2008 at 07:30:00PM -0400 Robert P. J. Day ha dit:
> 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.
i think it's a good idea, besides probably saving some bytes it
notably reduces boot-time. populate_rootfs() (init/initramfs.c) does
the following:
printk(KERN_INFO "checking if image is initramfs...");
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start, 1);
if (!err) {
printk(" it is\n");
unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start, 0);
free_initrd();
return 0;
}
it first unpacks the image to see if it is an initramfs or an initrd.
afterwards it unpacks the image again to populate the rootfs. this
takes a sensible amount of time, depending on the size of the
initramfs. by separating initramfs and initrd (what makes sense
anyway) we can get rid of the checking part cause we know the image is
(or should be) an initramfs (or initrd)
--
Matthias Kaehlcke
Embedded Linux Engineer
Barcelona
The assumption that what currently exists must necessarily
exist is the acid that corrodes all visionary thinking
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
