[comp.soft-sys.andrew] Suggestion for future releases

nsb@THUMPER.BELLCORE.COM (Nathaniel Borenstein) (02/13/90)

Here is a suggestion that probably wouldn't be overwhelmingly difficult
to incorporate into a future release, and that might help promote the
spread of Andrew throughout the world.

I'll start with the following observation:  dynamic loading, though
wonderful, is a severe portability problem.  This problem is alleviated
for most of us who use Andrew by the fact that the ITC has ported the
dynamic loader to lots of architectures.  However, it is a significant
road block for three situations:

1.  People running on non-ITC-supported machines.

2.  People currently running on supported machines who expect to
upgrade, in the future, to the hottest hardware whenever it comes out
(recall how long it took to get Sun-4 support!)

3.  People who want to base products on Andrew and are scared by the
*future* portability problems the dynamic loader might entail.

I believe that you could make life better in all these situations almost
without writing a single line of C code, though a significant amount of
Imakefile hackery will be required.  It seems possible that you could
have an variable that can be set in site.mcr that permits
non-dynamic-linking builds.  In other words, it skips all the makedo
commands and builds a set of normal runnable binaries.  (Actually, with
a wee bit more work, it could just build a single monster binary
("maxrunapp"?) that linked in EVERYTHING -- all the insets, AMS, the
whole shebang.)  This would probably NOT be the preferred way for people
to run Andrew when dynamic linking is available, but it would serve to
make Andrew instantly available on almost any reasonable UNIX box, and
would provide a nice guarantee that if you buy the latest hot new
machine, you can get Andrew running on it without a lot of effort.  (As
an aside, the maxrunapp idea might even be more efficient than dynamic
loading for running Andrew in a large timesharing-with-X-terminals
situation, as the entire Andrew code would then be shared in the text
space.)  People who bought the new boxes could use statically-loaded
Andrew until someone gets around to porting the dynamic loader.

As I said, this feature would require virtually no C coding, but would
take some work on the Imakefiles.  I think it would offer significant
benefits to the current and potential user communities, the most
important of which is the elimination of the fear of future portability
problems with new and unsupported machines.  (You could even set up a
default machine type, "unknown", which compiled this way.)

Any comments?  -- Nathaniel

jis@mtgzx.att.com (02/13/90)

Excerpts from info-andrew: 13-Feb-90 Suggestion for future releases
Nathaniel Borenstein@thu (2546)

> dynamic loading, though wonderful, is a severe portability problem. 
> This problem is alleviated for most of us who use Andrew by the fact
> that the ITC has ported the
> dynamic loader to lots of architectures.  However, it is a significant
> road block for three situations:

> 1.  People running on non-ITC-supported machines.

> 2.  People currently running on supported machines who expect to
> upgrade, in the future, to the hottest hardware whenever it comes out
> (recall how long it took to get Sun-4 support!)

> 3.  People who want to base products on Andrew and are scared by the
> *future* portability problems the dynamic loader might entail.

I agree. These have been our major concerns here, and we came very close
to giving up on Andrew altogether when we decided to move to Sun 4s. 

It seems to me that either it should be easy to build a non-dynamically
loded version of Andrew with a selection of modules loaded into static
load, or the Art of Porting the Dynamic Loader to new architectures
should be better documented, so that someone outside ITC can take a
reasonable crack at it. Moreover, even if the latter is done, the former
may still be desirable for reasons of use in timeshared machines etc.
that Nathaniel has mentioned further on in his message.

                            Jishnu Mukerji,  
                           jis@mtgzx.att.com, 
                           +1 201 957 5986,  
                        AT&T Bell Laboratories, 
                      MT 3K-423, 200 Laurel Ave., 
                           Middletown NJ 07748