From owner-freebsd-hackers  Tue Oct 15 17:11:31 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id RAA19990
          for hackers-outgoing; Tue, 15 Oct 1996 17:11:31 -0700 (PDT)
Received: from austin.polstra.com (austin.polstra.com [206.213.73.10])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA19984;
          Tue, 15 Oct 1996 17:11:29 -0700 (PDT)
Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id RAA08338; Tue, 15 Oct 1996 17:11:27 -0700 (PDT)
Message-Id: <199610160011.RAA08338@austin.polstra.com>
To: sos@freebsd.org
cc: hackers@freebsd.org
Subject: Re: Linux compat issue(s) 
In-reply-to: Your message of "Tue, 15 Oct 1996 20:16:41 +0200."
             <199610151816.UAA01759@SandBox.CyberCity.dk> 
Date: Tue, 15 Oct 1996 17:11:26 -0700
From: John Polstra <jdp@polstra.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > The Note section idea also doesn't solve the entire problem.  We could
> > mark our own FreeBSD ELF files with Note sections, so we could recognize
> > them.  But unless we could persuade the Linux people to do likewise, we'd
> > still be unable to distinguish between Linux ELF files and SVR4 ELF files.
> > This is going to be a problem no matter what we do, though.
> 
> So, you agree with me after all :)

:-)  I don't even know any more whether I "agree" with you.  I guess I
just have a slightly different perspective.

However, I must admit that you are beginning to swing me over to your
point of view ...

> Its not even enough to distinguish between Linux/FreeBSD (which we
> could with note sections) and the rest, we will eventually have to
> be able to tell Solaris/DGUX/Olivetti-SVR4/NCR-SVR4/whatnot from
> each other too, or we will be in hell anyway. I know for a fact
> that if we are going to do SVR4 emulation we will NEED a way to
> tell them apart.

Yes.

> So having a nice little util that marks the ELF header in ways for
> us to know is the ONLY solution to this problem, like it or not.

I like this idea.  We can't expect foreign files to arrive in a
recognizable state, so we need to be able to "brand" them ourselves.
The utility should also be able to "unbrand" a file, returning it to its
original form.

> I propose that we use some unused space in the ELF header. The ELF
> header starts with a 16byte char field, where only the first 8 are
> used in all the ELF/i386 incarnations I've seen, so we can put a
> 8 char text here for the platform (that can easily be seen with
> the file(1) cmd too). Simple, easy, nice hack, works....

This is the kind of hack that I've argued against all along.  But I
suppose it may be the only choice, if we want to be able to brand an
existing file.  We can't use my Note section idea, because adding a
header to the program header part of the file shifts everything else
down in the file, changes the addresses of things in the program, and
so forth.  It would be easy to add it in the link phase, but we are not
reasonably going to be able to control the link phase.

It _is_ starting to sound like I agree with you, isn't it? :-)

John
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth