[541] in Release_7.7_team
Re: sun4m_54
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun May 19 15:27:31 1996
To: Craig Fields <cfields@MIT.EDU>
Cc: danw@MIT.EDU, testers@MIT.EDU, release-team@MIT.EDU
In-Reply-To: Your message of "Sun, 19 May 1996 13:44:20 EDT."
<9605191744.AA01314@mad-scientist.MIT.EDU>
Date: Sun, 19 May 1996 15:27:16 EDT
From: Greg Hudson <ghudson@MIT.EDU>
First, I'd like to observe that any conformant locker should have a
"sun4bin," since $bindier on the suns is still "sun4bin" (and will
remain sun4bin forever), and $bindir is still supposed to work. This
is a straw man argument, though, since new platforms (right now, the
SGI) don't have a foobin.
That said, this is an issue I've spent a lot of time thinking about.
There are a lot of subleties that people miss. The problem is this:
We use very specific names for identifying the architecture
that binaries will run on (hardware + os + version number,
effectively). Users want us to, one way or another, use a
more general naming scheme, with the end goal that "every
platform will automatically find all the binaries that work on
that platform."
Although this goal is laudable, it's very difficult to achieve in the
face of several complicating factors:
* Incomplete binary compatibility: not all Solaris 2.3
binaries work under Solaris 2.4.
* Non-commutative binary compatibility: many Solaris 2.4
binaries don't run under Solaris 2.3.
* Non-transitive binary compatibility: not an issue here, but
platforms A and B may be able to run each others' native
binary formats, as well as B and C, but not A and C.
* Lack of anything resembling union mounts in AFS.
So, here are two proposed half-assed solutions and the ways they fail:
* We could go back to using more general names like "sun4,".so
that an operating system upgrade doesn't make you look for a
new set of binaries.
This fails because of incomplete binary compatibility
(people get old binaries that don't work) and, more
importantly, because of non-commutative binary
compatibility: it screws over users of the old operating
system as binaries are recompiled on the new platform. We
witnessed both problems when "sun4" was the machtype for
both SunOS and Solaris.
* We could associate a compatibility list with each platform
(e.g. "sun4m_54 is backward compatible with sun4m_53,
sun4m_51, and sun4m_412") and have "add" and "athdir" search
for binary directories for all platforms. This is an
extended version of what Dan suggested.
In addition to the obvious problem with incomplete binary
compatibility, the problem is that we only select one binary
directory for a given locker, so:
- As soon as the locker maintainer makes an
arch/sun4m_54/bin with one binary, you lose access
to all the arch/sun4m_53/bin binaries you were using.
- If you happened to be getting the arch/sun4m_412/bin
directory, and the locker maintainer adds an
arch/sun4m_53/bin directory with a few binaries, you
start losing even though the locker maintainer did
nothing directly related to your platform.
Also, as long as we are tethered to $bindir working (and we
cannot just ignore it; it's in the online help and we've
made no announcement that it will stop working), any scheme
which relies on a search procedure does not completely work.
Locker maintainers could make big symlink farms, but this dramatically
complicates locker maintenance if you attempt to respect all binary
compatibility; suddenly if I want to add a sun4m_412 binary, I need to
remember to make symlinks in all of the binary directories of
platforms that can run sun4m_412 binaries that don't already have
their own binaries.
Dan's suggestion would have some immediate benefit, but I'm not fond
of half-assed solutions that make life harder for us in the long run.
For now, we're going to require a little bit of effort from locker
maintainers when new platforms come out even when most old binaries
will run on the new platforms.
