Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!cmcl2!brl-adm!adm!bzs@bu-cs.bu.EDU
From: bzs@bu-cs.bu.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: multiple-machine executables for Suns?
Message-ID: <8708@brl-adm.ARPA>
Date: Fri, 7-Aug-87 21:54:19 EDT
Article-I.D.: brl-adm.8708
Posted: Fri Aug  7 21:54:19 1987
Date-Received: Sun, 9-Aug-87 07:19:10 EDT
Sender: news@brl-adm.ARPA
Lines: 45


I dunno, the proposal to put multiple executables into an a.out to
support sun-N at first glance seems like an obvious and
straightforward solution, but on a little deeper thought I wonder if
the solution should go in a slightly different direction, or at least
be thought about in more general terms.

First, the "officially sanctioned solution" from Sun is to use a
combination of directories, perhaps symlinks and path variable
settings. Thus a Sun-2 should search /usr.MC68010/bin while a Sun-3
should search /usr.MC68020/bin (etc.) I suppose the big glitch in that
is that both probably are really looking for /usr/bin but this can be
hidden by use of fstab and symlinks (/usr is symlinked to the
appropriate directory which is then mounted, eg. /usr -> /usr.MC68010
etc.) The Sun setup programs lead one in that direction.

I bring this up for two reasons. The first is that what appears to be
a solution exists and I'd be curious what the problem with that really
is, it adds no new features to the kernel and is fairly
straightforward to implement. The second is that this scheme plus the
extra inode for each binary probably takes up at least as much space
as your scheme (ie. not much, but the Sun solution is also non-zero,
there ain't no such thing as a free lunch) so Sun's comment on disk
space does not seem to hold water unless I am missing something.

Finally, with NFS spreading rapidly, I'd like to see this proposal
include (and consider, eg. header space layout, byte order) the
possibility of supporting many machine architectures simultaneously,
not just the Sun cross-section. If this doesn't seem possible or
practical then that should be explained (is it an example of the
best being the enemy of the good? or just not laid out in general
enough terms.)

I think I'd also like to see thought towards using existing
facilities.  Maybe the right approach is to teach exec() about
archives? Thus when an archive magic # is found in a header the
executable is extracted and loaded (is this too much hair? just an
example.) Of course, any of these naturally leads us towards some
cacheing mechanism to speed up frequently used items on a particular
machine (I dunno, sounds like a long route to get 'ls' loaded.)

Not passing judgement, just trying to point out what I see as
issues I don't see an obvious solution for off-hand.

	-Barry Shein, Boston University