[Top] [All Lists]

Re: head.S and init_task.c vs addinitrd

To: Guido Guenther <>
Subject: Re: head.S and init_task.c vs addinitrd
From: "Maciej W. Rozycki" <>
Date: Mon, 15 Apr 2002 16:09:41 +0200 (MET DST)
In-reply-to: <>
Organization: Technical University of Gdansk
On Mon, 15 Apr 2002, Guido Guenther wrote:

> >  Hmm, isn't that broken?  I believe an initial RAM disk should be added to
> > an ELF image, before converting it to ECOFF.  Not everyone uses ECOFF and
> > ELF is the "canonical" executable format for Linux.  Everything else is a
> > derivative.
> But we currently don't support relinking the ELF kernel to add a ramdisk,

 I don't know.  We are going to have to if the BOOTP/NFS-root code gets
removed, which will supposedly happen quite soon.

> do we [1]? Elf2ecoff/addinitrd is the only way I know of to achieve this
> and I still don't understand why the recent init_task.c/head.S changes
> where necessary which broke this.

 Maybe because that's an ugly hack (as I can see from your description).

> [1] I know that one can link a ramdisk into the ELF image but this
> ramdisk hat to be available at kernel compile time which is not an option in
> many situations(e.g. Debian "boot-floppies").

 It depends on how a kernel gets built.  If we add "-r" to the current
final link we'll get "vmlinux.o" that is a complete, self-contained
kernel, that may be linked against a RAM-disk (or just relinked alone) 
without a problem.  That's actually a generic solution and certainly
something like this will likely have to get implemented as soon as a
RAM-disk gets mandatory for block-device-less ;-) configurations. 


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>