is it worth separating initrd from initramfs support?

is it worth separating initrd from initramfs support?

[Robert P. J. Day]

  not sure if i asked this here once upon a time but, in the current
kernel, you get to select support for *both* initrd and initramfs with
a single selection (CONFIG_BLK_DEV_INITRD).

  however, folks who have been around a while generally associate the
feature INITRD with, well, an initrd image, while initramfs is
something a bit newer.

  in the context of embedded linux, is there any value in separating
these features and letting one select them individually?  isn't it
reasonable to think that one might need initramfs support but have
absolutely no use for "initrd" support?  or is that not worth worrying
about?

rday
--

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

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

Re: is it worth separating initrd from initramfs support?

[Leon Woestenberg]

Robert,

On Mon, Aug 4, 2008 at 8:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>  not sure if i asked this here once upon a time but, in the current
> kernel, you get to select support for *both* initrd and initramfs with
> a single selection (CONFIG_BLK_DEV_INITRD).
>
> ...
>
>  in the context of embedded linux, is there any value in separating
> these features and letting one select them individually?  isn't it
>
Makes sense to me to seperate them, especially if this reduces code size.

Small kernels and initramfs's are used in memory constrained systems,
we run it on FPGA SoC cores.

Does disabling initrd alone reduce code size? Is the dependency on
some subsystem removed (block i/o layer?)

Regards,
-- 
Leon

Re: is it worth separating initrd from initramfs support?

[Robert P. J. Day]

On Mon, 4 Aug 2008, Leon Woestenberg wrote:

> Robert,
>
> On Mon, Aug 4, 2008 at 8:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> >  not sure if i asked this here once upon a time but, in the
> > current kernel, you get to select support for *both* initrd and
> > initramfs with a single selection (CONFIG_BLK_DEV_INITRD).
> >
> > ...
> >
> >  in the context of embedded linux, is there any value in
> > separating these features and letting one select them
> > individually?  isn't it
> >
> Makes sense to me to seperate them, especially if this reduces code
> size.
>
> Small kernels and initramfs's are used in memory constrained
> systems, we run it on FPGA SoC cores.
>
> Does disabling initrd alone reduce code size? Is the dependency on
> some subsystem removed (block i/o layer?)

from a quick inspection, i *think* specifically disabling initrd
support would save a few bytes.  see the end of init/initramfs.c:

===========
static int __init populate_rootfs(void)
{
        char *err = unpack_to_rootfs(__initramfs_start,
                         __initramfs_end - __initramfs_start, 0);
        if (err)
                panic(err);
        if (initrd_start) {
#ifdef CONFIG_BLK_DEV_RAM
                int fd;
                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;
                }
                printk("it isn't (%s); looks like an initrd\n", err);
                fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 0700);
                if (fd >= 0) {
                        sys_write(fd, (char *)initrd_start,
                                        initrd_end - initrd_start);
                        sys_close(fd);
                        free_initrd();
                }
#else
                printk(KERN_INFO "Unpacking initramfs...");
                err = unpack_to_rootfs((char *)initrd_start,
                        initrd_end - initrd_start, 0);
                if (err)
                        panic(err);
                printk(" done\n");
                free_initrd();
#endif
        }
        return 0;
}
==========

  if you're interested in *only* an internal intramfs, surely some of
the code above could be dropped, no?  but that's just my first
impression.

rday
--

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

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

Re: is it worth separating initrd from initramfs support?

[Robert P. J. Day]

On Mon, 4 Aug 2008, Leon Woestenberg wrote:

> Robert,
>
> On Mon, Aug 4, 2008 at 8:53 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >
> >  not sure if i asked this here once upon a time but, in the
> > current kernel, you get to select support for *both* initrd and
> > initramfs with a single selection (CONFIG_BLK_DEV_INITRD).
> >
> > ...
> >
> >  in the context of embedded linux, is there any value in
> > separating these features and letting one select them
> > individually?  isn't it
> >
> Makes sense to me to seperate them, especially if this reduces code
> size.
>
> Small kernels and initramfs's are used in memory constrained
> systems, we run it on FPGA SoC cores.
>
> Does disabling initrd alone reduce code size? Is the dependency on
> some subsystem removed (block i/o layer?)

i'm going to move this discussion to the kernel-newbies list since
it's really not tightly related to embedded, we'll hash it out there,
and i'll report back.  i'm *reasonably* convinced that we can save
some bytes here, but i'll make sure, then i'll let you know.

rday
--

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

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