MobConnectionDoc.tioga
Copyright Ó 1989 by Xerox Corporation. All rights reserved.
Michael Plass, September 28, 1989 5:39:12 pm PDT
MobConnection
PCedar2.0 — FOR INTERNAL XEROX USE ONLY
MobConnection
Michael F. Plass
Ó Copyright 1989 Xerox Corporation. All rights reserved.
Abstract: Provides a simple client interface for accessing those parts of mob files (Mimosa symbol files) that have to do with the connections between modules. Also provides aid for figuring out what needs to be loaded, and in what order.
Created by: Michael F. Plass, June 1989
Maintained by: Michael F. Plass <Plass.pa>
Keywords: XLister, Cinder, Mimosa, Mob, Symbols, Programming Aids, MakeDo
XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304
For Internal Xerox Use Only
1. MobConnection
This interface provides simple client access to mob files, presenting information similar to that provided by the mob lister (XLister), but in a form more amenable to programs. It does not claim to provide comprehensive access to mobs, but the interface is intended to be general enough that this would be possible.
2. MobOrder
Client interface for the MobOrder command functionality.
3. Commands
MobOrder Foo.df ... -g Goal1 Goal2 ... -i Interface ... -x ModuleNamePattern ...
Builds a load order for all the modules needed by the goals.
The initial arguments are DF file names that describe all the mob files we have to choose from. The arguments after -g are the module names that we need loaded (the order will be preserved if possible). Preceding a goal by -i means we want all the importers of that interface to be treated as goals (useful for systems that register procedures with lower-level software).
The parameters preceded by "-x" is are taken as patterns for the names of modules that should NOT be goals, in spite of the other parameters. This is useful when a DF file contains test modules, obsolete programs, etc., that you don't want.
See the example below for more details.
Since this command necessarily pushes around a lot of files, it can take awhile. However, it does a lot of caching, so if you make a small change and try again soon, it goes pretty fast.
MobDependents Foo.df ... -g Interface1 Interface2 ...
Says what modules covered by Foo.df ... will need to be recompiled if the interfaces Interface1 Interface2 ... are changed. This works by traversing mobs, so the world should be consistent and properly described by the DF files for this to work well. However, it tries to recover from errors (you may have to proceed some signals that it currently does not catch).
4. Examples
Suppose you wished to build RawTioga.pcr, a pcr loadees file to start up Tioga, CommandTool, EditTool, TiogaToInterpress, and TiogaExecCommands on top of RawViewers. The first step is to make a DF file that describes all the mobs we might need:
% DFNeeds -i [PCedar2.0]<Top>CedarCore-PCR.df [PCedar2.0]<Top>TiogaExecCommands-PCR.df [PCedar2.0]<Top>TiogaImager-PCR.df [PCedar2.0]<Top>EditTool-PCR.df [PCedar2.0]<Top>RawViewers-PCR.df > RawTiogaNeeds.df
We don't have to explicitly say "Tioga-PCR", "Viewers-PCR", etc., because they reachable through the other DF files.
Next, use MobOrder to make a list of things to be loaded:
% MobOrder RawTiogaNeeds.df -g CedarCore BasicCedar StartRawViewersImpl TiogaPackage PCommandToolViewersPackage -i Commander > RawTioga.order
CedarCore must be an explicit goal, because there are other possibilities, e.g., NonthreadsCedarCoreWithFloat
BasicCedar must be an explicit goal, because of the presence of SoftcardBasicCedar
TiogaPackage is explicitly needed because of the presence of TEditPackage, etc.
PCommandToolViewersPackage is explicitly needed because of PCommandToolPackage
-i Commander means we want everything that imports the Commander interface to be goals; this should catch all the uses of Commander.Register.
Now we need another DF file that describes all of the sun4 object code we might need. It won't hurt if this describes more than the minimum (except for the time to process them all), so let's be exhaustive:
% ls -fob [PCedar2.0]<Top>*-Sun4*.df!h > PCedar-Sun4.ls
[[ now edit out the newlines and the comment at the bottom of PCedar-Sun4.ls, and ... ]]
% DFSort -i @PCedar-Sun4.ls > PCedar-Sun4.df
% DFPCRLoadees -r -o PCedar-Sun4.df sun4 "UnixLoad /volume/pixel1/pcedar2.0/cedarprebasics/sun4/cedarprebasics.~10~" "UnixLoad /volume/pixel1/pcedar2.0/cedarprebasicsextras/sun4/cedarprebasicsextras.~8~" "ReleaseLocation PCedar2.0 /volume/pixel1/pcedar2.0/" @RawTioga.order > RawTioga.pcr
The string literals go directly into the output, as separate lines.
The -r switch says to emit "RequireFrom" instead of "LoadAndRun" directives.
The output of all of this is the following (on September 20, 1989):
UnixLoad /volume/pixel1/pcedar2.0/cedarprebasics/sun4/cedarprebasics.~10~
UnixLoad /volume/pixel1/pcedar2.0/cedarprebasicsextras/sun4/cedarprebasicsextras.~8~
ReleaseLocation PCedar2.0 /volume/pixel1/pcedar2.0/
ORequireFrom PCedar2.0 CedarCore CedarCore
ORequireFrom PCedar2.0 BasicCedar BasicCedar
ORequireFrom PCedar2.0 DatagramSocket DatagramSocketImpl
ORequireFrom PCedar2.0 ThisMachine ThisMachinePackage
ORequireFrom PCedar2.0 MiscRegistry ThisMachineRegistryPackage
ORequireFrom PCedar2.0 SystemNames SystemNamesPackage
ORequireFrom PCedar2.0 UnixLibs UnixDirectoryImpl
ORequireFrom PCedar2.0 UFS UFSPackage
ORequireFrom PCedar2.0 Stubs MimosaStubs
ORequireFrom PCedar2.0 Loader LoaderPackage
ORequireFrom PCedar2.0 CedarProcess CedarProcessImpl
ORequireFrom PCedar2.0 CodeTimer CodeTimerPackage
ORequireFrom PCedar2.0 Imager ImagerPackage
RequireFrom PCedar2.0 TIP PTIPPackage
ORequireFrom PCedar2.0 UserProfile UserProfilePackage
RequireFrom PCedar2.0 Viewers ViewersPackage
RequireFrom PCedar2.0 SunTerminal SunTerminalImpl
RequireFrom PCedar2.0 RawViewers RawViewersImpl
ORequireFrom PCedar2.0 RawViewers StartRawViewersImpl
ORequireFrom PCedar2.0 PerformanceMon DummyPerformanceMonImpl
ORequireFrom PCedar2.0 TRope TRope
ORequireFrom PCedar2.0 Rosary RosaryImpl
RequireFrom PCedar2.0 TJaM TJaMPackage
ORequireFrom PCedar2.0 Tioga TiogaPackage
ORequireFrom PCedar2.0 Args ArgsPackage
ORequireFrom PCedar2.0 LRUCache LRUCacheImpl
ORequireFrom PCedar2.0 DFS DFSPackage
ORequireFrom PCedar2.0 MBQueue MBQueueImpl
RequireFrom PCedar2.0 BasicPackages PriorityQueueImpl
ORequireFrom PCedar2.0 ViewerIO ViewerIOImpl
ORequireFrom PCedar2.0 ReadEvalPrint ReadEvalPrintImpl
ORequireFrom PCedar2.0 SimpleStreams SimpleStreamsImpl
ORequireFrom PCedar2.0 VersionMap VersionMapImpl
RequireFrom PCedar2.0 CommandTool PCommandToolViewersPackage
ORequireFrom PCedar2.0 EditTool EditTool
ORequireFrom PCedar2.0 Interpress InterpressPackage
ORequireFrom PCedar2.0 TiogaImager TiogaImagerImpl
ORequireFrom PCedar2.0 TiogaImager TiogaToInterpressImpl
ORequireFrom PCedar2.0 TiogaExecCommands TiogaExecViewerCommands
ORequireFrom PCedar2.0 TiogaExecCommands TiogaExecCommands
ORequireFrom PCedar2.0 TiogaExecCommands AnnotateProperties
Some notes:
the ORequireFrom is used when a sun4-o3>...o is present and newer than the sun4>...o
BulletproofVestImpl has no mob file, and so MobOrder can't put it in. It could be inserted into RawTioga.order right after "BasicCedar"
ThisMachinePackage is obsolete, and should be removed by hand (from RawTioga.order).
The DFPCRLoadees step should be redone from time to time, as optimized versions get out of date.
You'll see all kinds of interesting warnings; most of these are due to things that ought to be fixed.
5. Another example (a fatter world)
Suppose you wished to build RawTools.pcr, a pcr loadees file to start up all of the above, plus the programming tools:
% DFNeeds -i [PCedar2.0]<Top>CedarCore-PCR.df [PCedar2.0]<Top>C2C-PCR.df [PCedar2.0]<Top>Cinder-PCR.df [PCedar2.0]<Top>Clock-PCR.df [PCedar2.0]<Top>DFCaching-PCR.df [PCedar2.0]<Top>DFCommands-PCR.df [PCedar2.0]<Top>EditTool-PCR.df [PCedar2.0]<Top>GetFromRelease-PCR.df [PCedar2.0]<Top>RawViewers-PCR.df [PCedar2.0]<Top>RunCommands-PCR.df [PCedar2.0]<Top>Scheme-PCR.df [PCedar2.0]<Top>TiogaExecCommands-PCR.df [PCedar2.0]<Top>TiogaImager-PCR.df [PCedar2.0]<Top>MakeDoCommands-PCR.df > RawToolsNeeds.df
Next, use MobOrder to make a list of things to be loaded:
% RawToolsNeeds.df -g CedarCore BasicCedar StartRawViewersImpl TiogaPackage PCommandToolViewersPackage -i MimSysOps -i Commander -i Scheme -x *Test* -x *Debug* -x *ThisMachinePackage* -x AnnotateProperties -x SchemeSupportImpl > RawTools.order
We can use the same PCedar-Sun4.df we made above:
% DFPCRLoadees -r -o PCedar-Sun4.df sun4 "UnixLoad /volume/pixel1/pcedar2.0/cedarprebasics/sun4/cedarprebasics.~11~" "UnixLoad /volume/pixel1/pcedar2.0/cedarprebasicsextras/sun4/cedarprebasicsextras.~8~" "ReleaseLocation PCedar2.0 /volume/pixel1/pcedar2.0/" @RawTools.order > RawTools.pcr