Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Aug 1996 15:27:55 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        chuckr@glue.umd.edu (Chuck Robey)
Cc:        terry@lambert.org, bwithrow@baynetworks.com, jkh@time.cdrom.com, lada@ws2301.gud.siemens.co.at, markd@Grizzly.COM, hackers@FreeBSD.org
Subject:   Re: What are the plans for ELF support?
Message-ID:  <199608092227.PAA19518@phaeton.artisoft.com>
In-Reply-To: <Pine.OSF.3.95.960809173034.553D-100000@modem.eng.umd.edu> from "Chuck Robey" at Aug 9, 96 05:40:06 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> Terry, I wonder, because of the fractionalization of the Linux
> marketplace, if there would be a large rush towards accepting your idea.
> What about this .... could WE use the idea on FreeBSD in a way that'd make
> the others jealous?
> 
> I wonder if it might be possible to make a conversion program that, when
> the user takes the responsibility of determining (from the user's
> experience in getting a particular piece of software) that it is 'type x',
> then this program would make the necessary adjustments in the binary elf
> structures so that it fully conforms to your spec, and is runnable on
> FreeBSD.
> 
> Can you tell me where your spec is?  Can I read it?  I know we couldn't
> make such a 'validator' program automatic, because of the problem with the
> current lack of info, but if we could rely on a user to specify the
> bona-fides of the program, maybe it could then be tagged that way?
> Something like this would have to be done only once, because once the
> program was 'validated' and made to conform to a spec, it would be
> binarily modified to run without further errors on ONE elf environment.
> 
> > 1)	produce the spec.

My suggested approach to getting a spec hashed out was to take the
Motorolla SVR4 EABI and hack it based on input from the Linux and
BSD camps and a "reference superset implementation", which would
allow a vendor to develop for one or more commercial UNIX
implementations at the same time as the free UNIX implementations.

That is, make it so that the ABI validation passed for Solaris, SCO,
or both, with a single exception of the "ABI-only" mode switch.


The SVR4 EABI spec is downloadable from the Motorolla FTP site, or
you can search for it on their WWW pages (www.motorolla.com); it was
in the PoerPC section.

A "FABIO" binary would be guaranteed to run on certified platforms,
and a binary could be certified as a FABIO binary on certified
platforms that had the "ABI-only" mode switch.

This means that, as a software vendor, I could develop a program
on a FABIO platform with the switch turned on, and get immediate
code coverage for the binary on NetBSD, OpenBSD, FreeBSD, Linux,
Solaris (and/or SCO), HURD (hopefully), etc..


I made the proposal because I believe that the main fragmentation
of the UNIX market has come from:

1)	"Standard plus extensions", with no real discrimination
	between what is "standard" and what is an "extention".
2)	No public reference implementation for all "standard"
	components... for FABIO, this means dropping Motif
	requirements (at least initially), etc.
3)	No way to certify an application for more than a single
	platform.  This is because there is no way to turn the
	extensions *off*.
4)	No common install tools set that is not "value add" by a
	vendor.  "value add" translated to "vendor specific".
5)	No validation mechanism without some absurd "buy-in"
	from a standards body (OSF, X/Open, ISO, ANSI, etc.).
	Think of POSIX validation; it costs ~$50,000, minimum,
	and even then, it doesn't mean that you can run applications
	because there is no "POSIX ABI" and there is way to make
	sure an app "only uses POSIX interfaces".  Bletch.
6)	etc....

In other words, the factors inhibiting the commoditization of the
UNIX market in the same way the DOS/Windows market is "commoditized"
by having a sole source (Microsoft).

This would let me (as an app developer) build one app, which I can
validate to the ABI instead of validating to the system, shrink wrap
the thing, and not be covering only a tiny market segment.


It's probably not in the interests of UNIX vendors, who sole claim
to fame is their proprietary iron where they run their "standards
compliant" OS... but it is *sure* in the interests of software
vendors who need an economic argument before they will port because
the market is so darn fragmented.


If it was adopted across platforms, then we could throw out ANDF to
go to instroction set based disassemblers/crossassemblers.  I have
seen several programs for converting SCO programs for x86 to run on
680x0 based NCR tower systems -- and that was back in the mid 1980's.


If you want, we can take this back to the news groups and try and
get the Linux and Hurd people involved.  If we can show we are
serious about it, either SCO or Sun might be incented to "kick in"
validation materials for their OS to baseline their ABI as the
standards "reference superset implementation".


I don't think this can be done without out at least one cross-vendor
link: the Linux people would count, the HURD people would count, and
a commercial vendor would count.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608092227.PAA19518>