ramdisks and ramfs and initramfs -- what can i avoid?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  based on a thread or two on some other mailing lists, i'm trying to
clarify what can be de-selected in terms of ramdisk or ramfs or initrd
support when building a kernel.

  it all started when someone noticed this in fs/Kconfig:

=====
config RAMFS
        bool
        default y
        ---help---
          Ramfs is a file system which keeps all files in RAM. It allows
          read and write access.

          It is more of an programming example than a useable file system.  If
          you need a file system which lives in RAM with limit checking use
          tmpfs.

          To compile this as a module, choose M here: the module will be called
          ramfs.
=====

  i'm sure you can appreciate that it's a little odd to have a Kconfig
option that is hard-selected to yes, while its own help text suggests
that it can be built as a module, and possibly be de-selected in its
entirety.  it's also amusing that that same help text claims that
RAMFS is "more of an programming example than a useable file system",
and yet i've been assured that it's absolutely essential to build a
kernel.

  is it?  is there no possible scenario that you might be able to
build a working kernel without RAMFS support?  what exactly do you
need it for?

  as i read it, it seems mandatory for initrd support (is that
correct?).  but init/Kconfig suggests that initrd is de-selectable:

=====
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.
=====

  so maybe i choose to leave out initrd support because i'm working
with an embedded system or something.  and on top of all that, RAM
disk support is also de-selectable (from drivers/block/Kconfig):

=====
config BLK_DEV_RAM
        tristate "RAM disk support"
        ---help---
          Saying Y here will allow you to use a portion of your RAM memory as
          a block device, so that you can make file systems on it, read and
          write to it and do all the other things that you can do with normal
          block devices (such as hard drives). It is usually used to load and
          store a copy of a minimal root file system off of a floppy into RAM
          during the initial install of Linux.

          Note that the kernel command line option "ramdisk=XX" is now
          obsolete. For details, read <file:Documentation/ramdisk.txt>.

          To compile this driver as a module, choose M here: the
          module will be called rd.

          Most normal users won't need the RAM disk functionality, and can
          thus say N here.
=====

  so i'm a bit confused.  what's required, and what's not?  and are
all the above properly defined in terms of dependencies?  i've just
started to read the appropriate docs, but if someone can clarify this,
i'd be ever so appreciative.

rday

p.s.  just to sum up, is it possible to build a working kernel without
initrd support?  without ramfs support?  without initramfs support?
with omitting any combination of the above?  and do the Kconfig
entries for those features actually make sense in terms of
dependencies?

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux