On Mon, Apr 15, 2002 at 04:09:41PM +0200, Maciej W. Rozycki wrote:
> 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).
Are you telling me the only reason for the changes in init_task.c/head.S
were made to break the elf2ecoff/addinitrd "hack"? Where exactly was
there a hack in head.S/init_task.c. Please point me to the line of code
since I don't understand enough about the kernel to see it.
>
> > [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.
That's 2.5 stuff. We should not break expected behavior in 2.4.
-- Guido
|