[lkml]   [1996]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Patch to support initrd with dynamic ramdisks.

On Thu, 5 Dec 1996, G.W. Wettstein wrote:

> First of all thanks to Paul Gortmaker for his work on dynamic and
AFAIK the code mainly comes from Chad Page and Theodore Ts'o.
Paul did the wunderful documentation ... and much more other stuff in the
kernel ;-)

> compressed ramdisk support. I am finding that his work makes single
> boot/root/rescue disks once again feasible. Also thanks to Werner
> Almesberger and Hans Lermen for their work on the initrd system. It
> in combination with the dynamic ramdisk support has been very useful
> in generating single disk starter systems.
> As I was developing our starter disk system last week I ran into what
> appears to be some inconsistencies between the initrd code and the
> dynamic ramdisk code.

Don't think so, see below.

[ patch deleted ]

> There is a very real chance that this whole patch is borne from
> operator error by my lack of understanding of the whole initrd
> sequence. I have read the initrd and ramdisk documentation files
> quite thoroughly and am convinced (in my mind) that the kernels
> without this patch do not conform to the documentation.

Well, AFAIK the docs are ok (hey, Werner writes excellent docs;-),
but there are two different ones

Documentation/ramdisk.txt (Paul Gortmaker)
Documentation/initrd.txt (Werner Almesberger, and a bit from me)

which should not be mixed together in relation to the goal.

Ok Greg, let me try (with my german style English) to explain _for what_
initrd was intended to be used. Given that ...

A) You have many ramdisk devices (/dev/ramX).

B) You want to load them with valuable stuff, e.g a disk image

C) You want to do something _before_ you mount the final root FS.

... then for B you can _either_ use 'load_ramdisk=1' (part of the ramdisk
code of A) _or_ you use initrd. It was _not_ intended to use both.
With initrd you also can realize C.

However, the initrd stuff _uses_ the ramdisk code internally, so you
always have to configure both into the kernel, if you want initrd

In detail you have the following possibilities to load a ramdisk:

1. Do it as described in Documentation/ramdisk.txt in order to load a
ramdisk image from a floppy that gets mounted as root FS.
(NOTE: only from a floppy).

2. Use Loadlin to load it (via the initrd code) from any DOS accessible
medium (harddisk, floppy, CDrom, network, flashram-card, e.t.c).
For this you have to specify

loadlin ... root=/dev/ram initrd=<DOSfilename>
You then have in principal the same as with (1), but you are not
restricted on the floppy. For (2) /linuxrc will _not_ be executed.
( This feature also works with LILO, but it doesn't make much sense )

3. Use the initrd stuff for its _real_ purpose and let /linuxrc load
and/or mount what ever you want. For this you have to define

... root=<_not_ /dev/ram> initrd=<filename>
And (important), the final goal is not what the _initrd code_ does ,
but what _your /linuxrc_ does. ( I'll give some examples below. )

The main difference between (1) and (2,3) is that the ramdisk image isn't
loaded by the kernel, but by the loader (LILO, LOADLIN, SYSLINUX and all
the 'mknbi type loaders' such as ETHERBOOT). Hence Linux needs not to
access any medium to execute /linuxrc.

Here are some examples what initrd can be used for:

1. Booting an initial Linux system for installation from CDrom:

- Have LILO installed on a floppy let it load zImage and initrd
Put the above LILO floppy on an El-Torito type bootable CDrom
and let your (modern) BIOS load directly from the CDrom.
LOADLIN loads the kernel and the initrd image from CDrom

- /linuxrc gets started, loads the appropriate harddisk and CDrom drivers
via insmod and either loads the final ramdisk image from CDrom
into a _second_ ramdisk (/dev/ram2) and defines /dev/ram2 as final
root device (via write to /proc/sys/kernel/real-root-dev )
just defines /dev/cdrom as root FS.

- after /linuxrc exits the real root FS gets mounted and the first
thing that your /etc/rc should do is to delete /dev/ram (containing
initrd) and free the space it has occupied.

2. Booting an installed Linux with a fully modularized kernel

- The kernel only needs to have some vital things configured in
(e.g. the ext2 FS), the rest can be modules (content in initrd)

- LILO is set up to load initrd, and the initrd also contains all those
modules that are needed for mounting the root FS.

- /linuxrc loads the modules via insmod and sets the final root device.

- et voila ...

3. A general purpose starter disk (as you seem to need, Greg)

- Make _one_ ext2 FS floppy, copy the zImage, the LILO-files and the
initrd.gz image onto it. The initrd.gz also must contain all needed
modules and of course /linuxrc.

- Install LILO on the floppy.

- When /linuxrc gets started it asks (or probes) for the modules needed,
loads them, set the final root device, ...

- et voila ...

As you see, there is no need to use initrd in conjunction with the normal
load_ramdisk type stuff. If you realy need it, well, let /linuxrc load
as many ramdisks as you want. This is much more flexible and doesn't need
any kernel patch. BTW, I 'suspect' your patch may break the current behave
of initrd (when to mount, when to keep /dev/initrd, when to just load).

> working out this problem and it would appear that the initrd code
> still has some major assumptions that the ramdisk will be allocated as
> a fixed memory segment. A more complete solution to the problem that
This isn't correct. The boot-loader just temporary loads the image into
_some_ location above the kernel and notifies the kernel _where_ the image
is. ( Note: this is a param in the setup.S header that the loader sets )
The kernel marks these pages as used, the initrd driver code makes a
device out of it (/dev/initrd, major=1,minor=250) and uses the ramdisk
code to load from that device into /dev/ram. Once /dev/initrd gets closed
it destroyes itself and frees the memory.
( Note: opening /dev/initrd is a 'one shot' )

Hope this has clarified understanding.


 \ /
  Last update: 2005-03-22 13:38    [W:0.035 / U:1.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site