selecting initramfs support without initrd?

selecting initramfs support without initrd?

[Robert P. J. Day]

  i'm not sure if this is the proper forum for this, but while
perusing the early boot code, i noticed that selecting the config
variable BLK_DEV_INITRD gives you support for both initramfs, and an
initrd image.

  however, with embedded systems, isn't it more common to use
initramfs and not need initrd at all (depending on the functionality
of the bootloader)?  and if that's true, might there not be some
benefit in splitting those two features (initramfs versus initrd) so
you could select initramfs all by itself, and not compile in any
initrd support whatsoever?

  based on a quick inspection of the source under init/, it would seem
that you could whack out sizable chunks of code if you had no need for
initrd, but i could be wrong.

rday
--

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

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

Re: selecting initramfs support without initrd?

[Leon Woestenberg]

Hello Robert,

On Wed, Jun 25, 2008 at 12:11 AM, Robert P. J. Day
<rpjday@crashcourse.ca> wrote:
>
> perusing the early boot code, i noticed that selecting the config
> variable BLK_DEV_INITRD gives you support for both initramfs, and an
> initrd image.
>
Yes, I thought initrd to disappear when no block drivers where
selected. (because initramfs does not depend on the disk block i/o
stuff).

I may be confused and cannot check at this moment. At least I am sure
I saw the idea or a patch, maybe in the -tiny patches?

Regards,
-- 
Leon

Re: selecting initramfs support without initrd?

[Rob Landley]

On Tuesday 24 June 2008 17:11:01 Robert P. J. Day wrote:
>   i'm not sure if this is the proper forum for this, but while
> perusing the early boot code, i noticed that selecting the config
> variable BLK_DEV_INITRD gives you support for both initramfs, and an
> initrd image.

It gives you support for an _external_ initramfs.  (I.E. the bootloader can 
load an external blob into memory and feed the physical address into the 
kernel via the ramdisk_start=12345 command line option.  If this blob gunzips 
to a cpio image, it's extracted into rootfs.  If it gunzips to a recognized 
filesystem type, it's used as an initrd.)

The one built into the kernel is always used and can't be disabled, that I am 
aware of.  If you have files in the static cpio archive and files in an 
internally supplied cpio archive, the file in the external one replaces the 
corresponding file in the internal one.

>   based on a quick inspection of the source under init/, it would seem
> that you could whack out sizable chunks of code if you had no need for
> initrd, but i could be wrong.

If you disable BLK_DEV_INITRD you'll still have a cpio image built into your 
kernel:

make allnoconfig
make -j 3

It's possible that inclusion of the external image loading logic should be 
based on a symbol other than BLK_DEV_INITRD, since initramfs can use that 
logic when you never use a ram disk block device.  It's a question of 
untangling stuff and figuring out how much config granularity you want...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.