From owner-freebsd-hackers Fri Aug 9 15:39:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA14316 for hackers-outgoing; Fri, 9 Aug 1996 15:39:40 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA14311 for ; Fri, 9 Aug 1996 15:39:37 -0700 (PDT) Received: from phaeton.Artisoft.COM by mail.crl.com with SMTP id AA27476 (5.65c/IDA-1.5 for ); Fri, 9 Aug 1996 15:38:36 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA19518; Fri, 9 Aug 1996 15:27:55 -0700 From: Terry Lambert Message-Id: <199608092227.PAA19518@phaeton.artisoft.com> Subject: Re: What are the plans for ELF support? To: chuckr@glue.umd.edu (Chuck Robey) Date: Fri, 9 Aug 1996 15:27:55 -0700 (MST) Cc: terry@lambert.org, bwithrow@baynetworks.com, jkh@time.cdrom.com, lada@ws2301.gud.siemens.co.at, markd@Grizzly.COM, hackers@FreeBSD.org In-Reply-To: from "Chuck Robey" at Aug 9, 96 05:40:06 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 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.