From: Ty Sarna <tsarna@endicor.com>
Message-Id: <199512061950.NAA16532@fezzik.endicor.com>
Subject: Re: ELF and Multiboot questions
To: etheisen@teclink.net (Erik M. Theisen)
Date: Wed, 6 Dec 1995 13:50:21 -0600 (CST)
Cc: port-i386@netbsd.org, tsarna@endicor.com
In-Reply-To: <199512060436.WAA04983@ozzy> from "Erik M. Theisen" at Dec 5, 95 10:36:13 pm
Organization: Endicor Technologies, Inc., San Antonio, Texas
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-port-i386@NetBSD.ORG
Precedence: list

Erik M. Theisen wrote:
> 
> New boot proms? No that's not practical.  But maybe an intermidiary a.out boot
> loader that loads an ELF kernel is.  Also, it is possible to embed an a.out stub
> program in an ELF exe.

But you still need to be able to generate a.out!

> ELF is here to stay.  Many platforms are moving in this direction.  ELF is

COFF was here to stay. Many platforms were moving in that direction.

Nothing is forever.

> Multiple format support is a tough nut to crack.  I'm not saying it can't be
> done, only difficult.  It will be blatant hackery and completly
> non-standard though.

I just don't buy this. For things like nm, simply provide a different ELF
version. (Which you'd need to write anyway if we went ELF cold-turkey.)
Let usr.bin/nm/Makefile look at MACHINE or MACHINE_ARCH (or even
MACHINE_OMF) and decide whether to built usr.bin/nm/aout/ or
usr.bin/nm/elf/. The assembler and linker might be a little bit more
difficult. Blatant hackery? No. No worse than having a zillion little
elf-to-whatever convertes and such spread out in the different port's
directories to convert to their native format (some of these exist
already as a.out-to-whatever... why rewrite them?).

Face it, just like there are platforms that need ELF, there are
platforms that need a.out.  It's going to have to stay in the toolchain. 
Further, sticking with a.out has advantges on many of the supported
platforms, especially wrt binary backward compatibility (right now
NetBSD 1.1 can be used to generate binaries for 1.0 without TOO much
hassle... it'd be a lot more work if the 1.1 toolchain knew only ELF)
and cross-OS emulation.

Besides, something else WILL come along to replace ELF one day, and then
we'll have to go through all this again. Better to bite the bullet now
and figure out how to reasonably support different formats on different
platforms.