THE IMAGE ACTIVATOR Overview History How the image activator works Known files and the install utility Security considerations Other uses of the image activator ------------------------------------------------------------------- OVERVIEW VMS does not have a formal loader The "loading" function is performed in two steps The image activator opens the image file, reads the image header, and prepares the page tables so that the virtual address space reflects the contents of the image. Pages are read into memory as they are needed by the normal page fault mechanism. Other steps are taken in preparation for execution of the image. The RMS image-specific data area is set up. The user stack is mapped and SP is loaded. The transfer address is passed back to the caller. ------------------------------------------------------------------- Overview, cont. The image activator is NOT a part of the memory management subsystem. If we adopt the usual layered view of an operating system ... +----------------------------------------------------------+ | | | +--------------------------------------------+ | | | | | | | +--------------------------------+ | | | | | | | | | | | +--------------------+ | | | | | | | | | | | | | | | +---------+ | | | | | | | | | NUCLEUS | | | | | | | | | +---------+ | | | | | | | | SYSTEM SERVICES | | | | | | | +--------------------+ | | | | | | RMS AND THE FILE SYSTEM | | | | | +--------------------------------+ | | | | COMMAND LANGUAGE INTERPRETER | | | +--------------------------------------------+ | | APPLICATIONS AND UTILITY PROGRAMS | +----------------------------------------------------------+ ------------------------------------------------------------------- Overview, cont. ... the image activator resides not only outside the system service layer but also outside RMS. +----------------------------------------------------------+ | | | +--------------------------------------------+ | | | | | | | +--------------------------------+ | | | | | | | | | | | +--------------------+ | | | | | | | | | | | | | | | +---------+ | | | | ------------------------- > NUCLEUS | | | | | | | | | +---------+ | | | | | | | | SYSTEM SERVICES | | | | | | | +--------------------+ | | | | | | RMS AND THE FILE SYSTEM | | | | | +--------------------------------+ | | | | COMMAND LANGUAGE INTERPRETER | | | +--------------------------------------------+ | | APPLICATIONS AND UTILITY PROGRAMS | +----------------------------------------------------------+ The image activator is a consumer of the memory management system services. The image activator also uses RMS services (to gain access to image files). ------------------------------------------------------------------- Overview - Image headers The image header contains control and status information and a list of image section descriptors. The image section descriptors contain the information that describes how the image will occupy virtual address space. +------------------------+ ----------> +------------------------+ | | | | | IMAGE HEADER | | CONTROL FLAGS | | | | | +------------------------+ - | IMAGE IDENTIFICATION | | | \ | | | IMAGE BODY | \ | TRANSFER ADDRESS | | | \ | | | | \ +------------------------+ | CODE | \ | | | | \ | IMAGE SECTION | | | \ | | | DATA | \ | DESCRIPTORS | | | \ | | +------------------------+ -> +------------------------+ IMAGE FILE IMAGE HEADER An image file is interpreted as a stream of bits that must be verified before the image activator performs any work. ------------------------------------------------------------------- Overview, cont. The activation of an image consists of three simple steps. The image file is opened The image header is read and verified Each ISD is processed (converted into appropriate memory management system services) ------------------------------------------------------------------- Overview - Image Section Descriptors Each image section descriptor (ISD) describes a portion of virtual address space. ISD for Private Section - The code or data can be found in the image file (or in a global section). Demand-Zero ISD - A range of virtual addresses will start out as pages filled with zeros. Global ISD - The code or data can be found in a shareable image. The image activator will convert each ISD into a system service call. ------------------------------------------------------------------- History of the Image Activator Version 1 The Version 1 image activator adhered literally to the conceptual model Section ISD Create and Map (Private) Section (or Map Global Section) Demand-Zero ISD Create Virtual Address Space Global ISD Map Global Section (or Create and Map Private Section) ------------------------------------------------------------------- History of the Image Activator Version 2 Protected shareable images (used to implement user-written system services were introduced). The contents of the image header cannot be trusted. The response of the image activator was slightly modified. Section ISD Create and Map (Private) Section Demand-Zero ISD Create Virtual Address Space Global ISD Call the Image Activator ------------------------------------------------------------------- History of the Image Activator Version 2, cont. During the recursive call, the image activator mapped the pages of a shareable image using a modified set of rules. Section ISD Create and Map (Private) Section Demand-Zero ISD Did not exist Global ISD Ignored ------------------------------------------------------------------- History of the Image Activator Version 2, cont. Version 2 also introduced the notion of a merged activation, where a shareable image was placed into the address space, usually at the end. DEBUG and TRACEBACK were mapped this way. DCL was mapped into P1 space using a modified version of the same technique. ------------------------------------------------------------------- History of the Image Activator A Problem Shareable images were bound to specific virtual addresses in the image header of a main program. Only the shareable image mapped at the end can grow without requiring the main program to be relinked. Suppose a program references two shareable images: LBRSHR and VMSRTL. +-------------------+ | | | MAIN PROGRAM | | | +-------------------+ | | | LBRSHR | | | +-------------------+ |\\\\\\\\\\\\\\\\\\\| +-------------------+ | | | | | VMSRTL | | | | | +-------------------+ ------------------------------------------------------------------- History of the Image Activator A Problem, cont. If LBRSHR grows larger than its allocated space (beyond the base address of VMSRTL), then the main program must be relinked. +-------------------+ +----------------------+ | | | | | MAIN PROGRAM | | MAIN PROGRAM | | | | | +-------------------+ -------------> + - - - - - - - - - - -+ | | . . | LBRSHR | . REVISED LBRSHR . | | . . +-------------------+ ---- . . |\\\\\\\\\\\\\\\\\\\| \ . . |\\\\\\\\\\\\\\\\\\\| \ . . +-------------------+ \ +----------------------+ | | ------> + - - - - - - - - - - + | | | | | VMSRTL | | VMSRTL | | | | | | | | | +-------------------+ +----------------------+ Note that VMSRTL can grow without upsetting references to LBRSHR. ------------------------------------------------------------------- History of the Image Activator Version 3 Version 3 saw the introduction of image activation time binding. Addresses associated with shareable image were "fixed up" (by adding shareable image base addresses) at activation time. No changes in the way that ISDs were transformed into system service calls. Image activator call sites were modified to add a call to the fixup routine. These fixups were done in USER mode. ------------------------------------------------------------------- History of the Image Activator Version 3, cont. Shareable images could be relinked (and occupy more space) without forcing the main program to be relinked. This allowed a more flexible pattern of reference among images. As a result, independent development of application packages (and layered products) as shareable images flourished. ------------------------------------------------------------------- History of the Image Activator A Problem The names of all shareable images referenced by any image had to appear in the image header of the main program. Consider the following example. VMSRTL ^ ^ / \ / \ A --> C <--B ^ ^ \ / \ / MAIN ------------------------------------------------------------------- History of the Image Activator A Problem, cont. If B were relinked to reference shareable image D, the activation of the main program would fail until the main program was relinked (and included a global ISD for D). VMSRTL VMSRTL ^ ^ ^ ^ -> D / \ / \ / / \ / \ / A --> C <--B A --> C <--B ^ ^ ^ ^ \ / \ / \ / \ / MAIN MAIN ... or VMSRTL could be relinked to reference BASRTL, COBRTL, FORRTL, LIBRTL, and MTHRTL ... ------------------------------------------------------------------- History of the Image Activator Version 4 The image activator was rewritten from scratch (but its external interface was preserved). The "recursive" call was replaced with a work list approach. When an image is activated, a work list element with its name is placed into the image activator's work list. After an image is opened, its ISDs are processed according to the following rules. Section ISD Create and Map (Private) Section Demand-Zero ISD Create Virtual Address Space Global ISD Add "global" image name to work list ------------------------------------------------------------------- Operation of the Image Activator Each element is removed from the work list and processed. A check is made to see if the image has already been mapped. (Does another work list element of the same name exist on the done list.) The image file is opened (if that step has not already occurred). The IHD is verified and the ISDs are processed. This continues until the work list is emptied. ------------------------------------------------------------------- Operation of the Image Activator Commonly referenced shareable images (such as LIBRTL) may appear on the work list several times ... but are only mapped once. Shareable images do not have to appear in the IHD of the executable image in order to be mapped. (This implies even fewer dependencies among images.) The done list exists for the life of the main program, providing a record of images mapped and address ranges occupied by each shareable image. More context can be shared between the activation of a main program and the activation of shareable images referenced by that program. ------------------------------------------------------------------- Operation of the Image Activator An Example Suppose that we have a set of images with the following reference pattern. LIBRTL <-+ ^ ^ | / \ | / \ | / \| A-->FORRTL<--B ^ ^ \ / \ / \ / MAIN ------------------------------------------------------------------- Operation of the Image Activator An Example, cont. Work List In Progress Done List --------- ----------- --------- main program The activation begins when the main program is placed into the work list. ------------------------------------------------------------------- Operation of the Image Activator An Example, cont. Work List In Progress Done List --------- ----------- --------- A (main) main program B (main) FORRTL (main) LIBRTL (main) As the ISDs in the main program are processed, images are added to the work list. ------------------------------------------------------------------- Operation of the Image Activator An Example, cont. Work List In Progress Done List --------- ----------- --------- B (main) A main program FORRTL (main) LIBRTL (main) FORRTL (A) LIBRTL (A) The global ISDs in shareable image A also make contributions to the work list. ------------------------------------------------------------------- Operation of the Image Activator An Example, cont. Work List In Progress Done List --------- ----------- --------- FORRTL (main) B main program LIBRTL (main) A FORRTL (A) LIBRTL (A) FORRTL (B) LIBRTL (B) The work list continues to grow but the new entries are all duplicates. ------------------------------------------------------------------- Operation of the Image Activator An Example, cont. Work List In Progress Done List --------- ----------- --------- LIBRTL (main) FORRTL main program FORRTL (A) A LIBRTL (A) B FORRTL (B) LIBRTL (B) LIBRTL (FORRTL) LIBRTL is added to the work list again. ------------------------------------------------------------------- Operation of the Image Activator An Example, cont. Work List In Progress Done List --------- ----------- --------- FORRTL (A) LIBRTL main program LIBRTL (A) A FORRTL (B) B LIBRTL (B) FORRTL LIBRTL (FORRTL) Because LIBRTL does not reference any other shareable images, nothing new is added to the work list. ------------------------------------------------------------------- Operation of the Image Activator An Example, cont. Work List In Progress Done List --------- ----------- --------- duplicates main program A B FORRTL LIBRTL At this point, the rest of the work list is emptied with no images encountered that have not already been mapped. Note that implicit as well as explicit shareable image references appear in an image header. ------------------------------------------------------------------- Future Plans and Dreams Performance Improvements Images activated into P1 space (once in the life of a process) or into system space (once in the life of the system). Image activation deferred until an image is referenced for the first time (on demand activation). Allow outbound calls from a privileged shareable image (probably restricted to other privileged shareable images). Demand zero sections in shareable images. "Group" installation of shareable images. ------------------------------------------------------------------- Known Files and the INSTALL Utility The known file list allows an image file to be quickly opened. Known Image image file will be opened by file ID OPEN image file is permanently opened HEADER image header is kept in memory, avoiding another read operation Known file list was formerly a sequential list, with one list for each device, directory, file type combination. The list is now hashed, with all known images combined together (and qualified by device and directory). ------------------------------------------------------------------- Security Considerations When an image installed with privilege is active, the image activator goes into paranoia mode. All shareable images referenced by the privileged image must be installed. RMS uses only "trusted" logical names when opening image files (EXEC or KERNEL names). The image activator "cooperates" with the CLI (conveys its sense of paranoia). A different form of paranoia holds sway when activating a privileged shareable image. (Such images cannot reference other shareable images.) ------------------------------------------------------------------- Other Uses of the Image Activator The image activator maps the RSX AME to allow execution of compatibility mode images. Image-specific message files are mapped by the image activator. LIB$FIND_IMAGE_SYMBOL is a jacket routine for the image activator. While not very efficient, the image activator can run images from magtape or over the net (or, perish the thought, from TT:).