Operating System architecture with reserved memory space resident program code identified in file system name space5594903Abstract A computer architecture having a main memory suitable for the storage of programs and data accessible within a predefined memory address space, a central processor capable of accessing the memory address space and a modified disk operating system program capable of execution from ROM or in a diskless environment. The operating system, upon execution by the processor, provides for the reservation of a first portion of the memory address space for support and application programs, preferably in a disk paradigm, a second portion for dynamic allocation and recovery by the operating system as necessary for the execution of support and application programs, and a third portion, located within said second portion, for the static storage, at predefined addresses, of the executable code segments of the support and application programs. Each support and application program includes an address reference to its corresponding executable code segment, in the third portion of the memory address space. Claims We claim: Description BACKGROUND OF THE INVENTION
TABLE I
______________________________________
"COFF" Program Structure
Program Header
filehdr # file header
a.outhdr # Unix system header
scnhdr 1 # code section header
scnhdr 2 # data section header
scnhdr 3 # bss section header
Program Code .code # code section storage
Program Data .data # initialized data
section storage
.bss # uninitialized data
section storage
symbols # symbol table data
section storage
"a.out" Program Structure
Program Header
a.sub.-- magic
# type of a.out file
a.sub.-- text
# .code segment size
a.sub.-- data
# .code segment size
a.sub.-- bas
# .code segment size
a.sub.-- syms
# .code segment size
a.sub.-- entry
# entry point
a.sub.-- trsize
# text relocation size
a.sub.-- drsize
# data relocation size
Program Code .code # code section storage
Program Data .data # initialized data
section storage
.bss # uninitialized data
section storage
symbols # symbol table data
section storage
______________________________________
However, as shown in FIG. 4b, the program structure preferred for application programs stored on the ROM disk 76, in accordance with the present invention, excludes the program code segment. Thus, an application program 110 as stored by the ROM disk 76 includes principally only a program header 112 and a data segment 114. Conventionally, an entire application program must be placed in RAM prior to execution. This results in a loss of main memory space equal to at least the size of the duplicated code segment. Moreover, a code segment must be effectively within the transient program area and aligned with a page boundary in order to permit execution. Page boundary alignment is a typical requirement of memory management and access protection control mechanisms. Typical page sizes range from 512 bytes to 16 kilobytes with an often preferred page size of four kilobytes. Location of application programs within a file system, such as the ROM disk 76 to meet the page alignment requirements alone, while possible, would not be optimal given the wide variety of file sizes and types. Therefore, the code segments for the programs stored on the ROM disk 76, including the program 110, are separately stored in the stripped code segments area 78. Since, in the preferred embodiments, the page size for application programs within the transient program area 66 is fixed at 4 Kbytes, the code segments 116, 118, 120, 222 provided within stripped code segments area 78 are stored aligned with 4 Kbyte page boundaries. Where, for example, a code segment 120 does not end on a page aligned boundary, a gap 124 must be provided so that a subsequent code segment 122 is again aligned on a 4 Kbyte page boundary. As can be seen from Table I, using a COFF structure program as an example, an application program is normally logically contiguous. That is, no provision is made in the structure of the program itself to identify where the component parts of the program are relative to one another. If there is any fragmentation of the program as stored by the file system, then the operating system must separately provide the ability to reconstruct the program. However, the present invention specifically provides for provision of the code segments 116, 118, 120, 122 logically separate from their corresponding program headers and, indeed, not even physically present in the file system. Instead, the stripped code segments area 78 is a reserved area of main memory 14 consisting of code segments that can be logically included in the transient program area 66 upon execution of the corresponding application program. Thus, the code segments 116, 118, 120, 122 are executed directly at their addresses as stored within the nonvolatile memory area 62. The corresponding data segments must be located in RAM memory to allow execution. On execution of, for example, application program 110, the program header 112 provides the address of the corresponding code segment 120. An exemplary description of the COFF type file header, "a.out header" and section header as used in a preferred embodiment of the present invention is given in Table II.
TABLE II
______________________________________
Program Header Structure
______________________________________
struct filehdr {
unsigned short f.sub.-- magic;
/* file magic number */
unsigned short f.sub.-- nscns;
/* number of sections */
long f.sub.-- timdat;
/* time & date stamp */
long f.sub.-- symptr;
/* file ptr to symtab */
long f.sub.-- nsyms;
/* no. symtab entries */
unsigned short f.sub.-- opthdr;
/* sizeof (opt hdr) */
unsigned short f.sub.-- flags;
/* flags */
struct a.outhdr {
short magic; /* file magic number */
short vstamp; /* number of sections */
long tsize; /* time & date stamp */
long dsize; /* file ptr to symtab */
long bsize; /* no. symtab entries */
short entry; /* sizeof (opt hdr) */
short text.sub.-- start;
/* base virtual code
addr */
short data.sub.-- start;
/* base virtual
data addr */
}
struct scnhdr {
char s.sub.-- name[SYMMLEN];
/* section name */
long s.sub.-- paddr;
/* physical address */
long s.sub.-- vaddr;
/* virtual address */
long s.sub.-- size; /* section size */
long s.sub.-- scnptr;
/* raw data ptr */
long s.sub.-- relptr;
/* relocation ptr */
long s.sub.-- lnnoptr;
/* line no.s ptr */
unsigned short s.sub.-- nreloc;
/* # reloc. entries */
unsigned short s.sub.-- nlnno;
/* # line no. entries */
long sflags; /* flags */
}
______________________________________
The magic numbers, "f.sub.-- magic" and "magic", are used by the operating system program loader to identify certain aspects of how the program is to be located in RAM memory for execution. The magic numbers are merely pre-defined constants that are defined by convention for Unix operating system application programs. A magic number of 0514, for example, indicates that the operating system program loader is to load the code segment, including the program header, in RAM memory beginning at a context specific virtual location of 0x00000000. Program data is located in the context specific virtual address space immediately following the end of the code segment. Typically, though specifically depending on the size of the program header, the actual ".code" segment will be located at a context specific virtual address of 0x000000A8. In accordance with the preferred embodiments of the present invention, a new magic number of 0410 ("IMagic") is introduced to identify application programs, otherwise identifiable as a magic number 0514 type executable program, whose code segment has been stripped and located within the stripped code segments area 78. The actual physical address of the corresponding code segment is placed into the IMagic identified program header 112 to allow the operating system program loader to locate the corresponding code segment 120. In COFF style program headers, the code section header maintains a conventionally unused data field "s.sub.-- paddr". Since, in the Unix operating system environment, application programs are executed within a virtual memory space, this physical address field, though defined, has had no identifiable use. Any physical address in a virtual address space is the same as the virtual address. Thus, only the s.sub.-- vaddr address value is used. However, the present invention advantageously utilizes this field for storing the physical address of the corresponding code segment. If, instead, an older style "a.out" program header format is used, the physical address of the code segment is inserted into the code stripped program structure immediately between the program header and data segment. Since an "a.out" program header includes a magic number field, the presence of the physical address is known and can be skipped in referencing the program data segment. In both cases, the operating system program loader is able to properly identify the corresponding code segment 120 and include it within the execution context of the application program 110. Since code segments contain unmodifiable code only, the code segments 116, 118, 120, 122 may be readily executed from nonvolatile memory. Further, separate instantiations of the application program 110 may each include a particular code segment 120 within its execution context; separate images of the code segment 120 are not required. Referring again to FIG. 3, the alterable portion 64 of memory is initialized, in the preferred embodiments of the present invention, to include the initial interrupt vector table 80, a copy of the OS data segment 72' transferred from the nonvolatile memory 62, an uninitialized OS ".bss" segment 82, and an image of the operating system symbols 74'. The OS ".data" segment 72' and OS .bss segment 82, in general, provide for storage of operating system data tables 94, including a stack pointer 96 and the page tables 98 utilized in the management of their virtual memory address space. For compatibility purposes, where application programs need to create data files, a RAM disk 84 may be allocated within the transient program area 66. For example, the RAM disk 84 may be initialized to incorporate several file systems including a temporary file system mounted as "/tmp" on the root file system formed in the ROM disk 76. Many application programs assume that this directory exists and is available for the writing of scratch files. The RAM disk "/tmp" directory thus realized is writable although the root file system itself is not. Other file systems may be configured and mounted as appropriate to the needs of the specific application programs to be executed. The RAM disk 84 may also provide for the storage of application programs transferred to the computer system 10 via, for example, a detachable disk sub-system 20 or a network 30. Such applications will have the conventional program structure shown in Table I. Accordingly, the magic number provided in the program header of such application programs will be the conventional magic number as supplied with the application program. Consequently, the operating system program loader will recognize and treat such non-stripped code segment application programs as requiring image copies of both code and data segments to be transferred from the RAM disk 84 into otherwise unallocated portions of the transient program area 66. Thus, for example, application programs one and two, containing only a program header and data segment are stored on the ROM disk 76. Corresponding code segments are stored in the stripped code segments area 78. A third application program is stored either on the ROM disk 76 or RAM disk 84. This third application has a non-stripped program structure including a program header, code segment and data segment. The program headers of applications one and two are modified to reflect the fact that their corresponding code segments have been stripped. Consequently, on launch of each of the three application programs, an image copy of the data segments of applications one and two 86, 88 are placed in the transient program space 66, while an image copy of both code and data segments 90, 92 must be copied to the transient program space 66. Consequently, the code segment 90 of application program three requires duplicative code segment storage within the address space portion 60. Further, depending on the size and fragmentation of the transient program space 66 a substantial delay may be incurred in transferring the code segment of the third application program into the transient program space 66. Another representation of a virtual address space portion 130 of the main memory 14, configured in accordance with an alternate preferred embodiment of the present invention, is shown in FIG. 5. Significantly, this virtual address space portion 130 is populated only with a small nonvolatile memory portion 132, containing an operating system boot loader program. The remainder of the address space portion 130 is implemented through the use of RAM memory. In this configuration, the present invention is best suited for use as a communication node or diskless workstation. A maximum amount of the virtual address space is implemented as RAM, allowing the greatest degree of flexibility in the operation of the computer system 10. Further, revisions and reconfigurations of the operating system may be readily performed remotely and transferred in response to the function of the operating system boot loader 132. In accordance with this embodiment of the present invention, the initial loading of the operating system and associated set of application programs is expedited through the image preparation of the download files. The operating system boot loader program 132 is again preferably located at the default execution address known to the CPU 12. In this embodiment, the boot loader program 132 incorporates sufficient operational capability to direct at least basic network communications operations through the network interface 26 to request and receive a succession of data packets providing an image copy of the interrupt vector table 80, OS ".code", ".data", and ".bss" segments 70, 72, 82, the OS symbol table 74, root RAM disk 134, and stripped code segments area 136. This image is loaded, preferably, beginning at low physical memory. Once loaded into memory, the use and operation of this alternate embodiment of the invention, as represented by the virtual address space portion 130, differs from that of the address space portion 60 only in the terminal operation of the boot loader program. That is, since the initial image of the OS data segment 72 and OS symbols 74 are already present in RAM, a further image copy is not required. Although the page tables 98 provided for in the OS data segment 72 could be pre-initialized with respect to the allocation of, for example, a secondary RAM disk 84 in the transient program area 66, this preferred embodiment of the invention does not so provide. Rather, a common operating system external initialization procedure is utilized by the boot loader program 68, 132 prior to initiating the execution of the operating system code segments 70. Creation and configuration of the secondary RAM disks 84 is performed by the internal initialization operations of the operating systems 70. Consequently, the changes and distinctions between embodiments of the present invention necessary to realize operation in the forms represented by the virtual address space portions 60, 130 are minimized. The process of preparing and using the preferred embodiments of the present invention will now be described particularly with reference to the preferred operating system embodiment, which is consistent with the architecture of the Unix operating system. The first step in preparing an operating system and related data and program image is to prepare an image of the operating system kernel itself. This image requires inclusion of a pseudo-disk device driver. Any other desired device drivers must be included at this time. The operating system kernel must be configured at this time with respect to the allocation and identification of system resources to be used by the kernel. If this operating system kernel is to be downloaded to a computer system 10, then the uninitialized portion of the data segment, specifically the ".bss" segment, is preferably deleted from the kernel image. Finally, a "node.sub.-- table" data table is constructed to identify the logical devices known to the kernel image, including their major and minor device numbers, whether the devices are logical block or character devices, and the device permissions. The second step is to prepare a root file system image that logically corresponds to the intended operating system root file system. This can be easily accomplished by creating a directory structure, typically from a temporary root node, that matches the intended root file system directory structure. All of the supporting operating system data files and application programs are then copied into their proper locations within this directory structure. All data tables must be edited at this point to match the intended operating environment and resources of the operating system environment, particularly where the image is to be placed in ROM. Finally, the "node.sub.-- table" data is used at this point to create the logical device files ("/dev/ . . . ") that are to be used by the operating system. The third step is to prepare a stripped code segments file. All of the application programs present in the image root file system that are to have their code segments stripped are identified. Each identified application program is processed to copy the code segment to the stripped code segments file aligned on a memory page boundary. The corresponding program header is then updated to change the magic number to the IMagic value and to insert the eventual physical address of the code segment into the physical address field of the header. Since the size of the executable operating system image and related data structures, including the root file system and any prior stripped code segments is known, the eventual physical address of this code segment can now be calculated. Finally, the structure of the application program as stored in the root file system is modified to exclude the code segment by concatenating the program header with the program data segment. A final fourth step is to prepare a single file containing the complete set of images necessary to construct the operating system. An initial 512 byte block is preferably placed into this destination file. An image of the operating system, as configured, and including the program data and OS symbols segments are placed in the destination file. An image of the root file system is then appended. The stripped code segments area image is then appended to the destination file. Finally, the first 512 byte block is updated to have an image copy of the program header appearing at the beginning of the operating system image. That is, the operating system is itself an executable program and is therefore conventionally created with a standard program header. In copying this program header to the beginning of the first 512 byte block, the magic number is changed to the IMagic value. A kernel information structure is then copied into the first 512 byte block immediately following the program header. Table III provides a C language definition of the preferred kernel information structure.
TABLE III
______________________________________
Kernel Information Structure
______________________________________
struct rkinfo {
unsigned long rk.sub.-- magic;
/* ROMable kernel magic
number */
unsigned long rk.sub.-- osend;
/* End of ROMable kernel
file */
unsigned long rk.sub.-- ramdisk;
/* Beginning address of
ram/rom disk */
unsigned long rk.sub.-- entry;
/* Alt. entry point */
unsigned int rk.sub.-- rootdev;
/* Root device */
unsigned int rk.sub.-- reboot;
/* Reboot status */
unsigned int rk.sub.-- flags;
/* Misc. flags */
unsigned long k.sub.-- base;
/* Base memory size */
______________________________________
The elements of the kernel information structure are defined as follows:
______________________________________
rk.sub.-- magic:
this is the ROMable kernel magic number
This must be IMagic.
rk.sub.-- osend:
end of operating system. Includes the
operating system and OS data, RAM/ROM
disk image and stripped code segments
area, if any. This is the first address
that is available to the operating
system for its own use and for user
applications. Determined upon
construction of the full operating
system image.
rk.sub.-- ramdisk:
starting address of "root" RAM/ROM disk.
This is always at a fixed address that
is determined by kernel size.
rk.sub.-- entry:
Operating system execution entry point.
rk.sub.-- rootdev:
Logical device id of the "root" RAM/ROM
disk. This is determined from
"node.sub.-- table" entry for /dev/rd0 during
construction of the full operating
system image.
rk.sub.-- reboot:
This allows passing of reboot flags to
the operating system.
rk.sub.-- flags:
Flags used by kernel. One flag
specifies whether the main memory of a
diskless node is fragmented. Another
flag specifies that the OS boot loader
is to automatically expand the ".bss"
segment on operating system load.
rk.sub.-- base:
Size of base memory if main memory is
fragmented. For example, 640K of memory
on Intel i386 CPU based machines.
______________________________________
The values of the kernel information structure are all calculable prior to the writing of the structure into the first 512 byte block. Thus, the operating system image destination file so constructed is complete and ready for use. While the first two steps are substantially manually executed steps, the third and fourth steps are readily performed by a utility program in the preferred embodiment. A control state flow diagram is provided FIG. 6 to illustrate the loading of an operating system image file for execution. A pseudo-code representation of this process is given in Table IV.
TABLE IV
______________________________________
OS Boot Load Procedure
______________________________________
If not a ROM OS then
OS boot loader requests and receives blocks
from default communications port
Receive .code segment
Receive .data segment
If rk.sub.-- flags = expand .bss then
allocate .bss segment space
clear .bss segment to 0
Else
Receive .bss segment
Receive OS Symbols, etc.
Else
Load .data segment to RAM
Allocate .bss segment space in RAM
Clear .bss segment to 0
Load OS Symbols, etc. to RAM
End.sub.-- if
OS boot loader jumps to OS entry point (rk.sub.-- entry)
with pointer to rk.sub.-- info structure
OS executes internal start-up procedures
page tables initialized; stripped code
segments area not included as allocable
memory
pseudo-disk device driver initialization
routine is executed to establish root
pseudo-disk drive; initial address of
pseudo-disk drive is specified by
rk.sub.-- info.rk.sub.-- ramdisk
other device driver initialization routines
are executed
root device is mounted using the logical
device specified by rk.sub.-- info.rk.sub.-- rootdev;
corresponds to the root pseudo-disk
drive
start/initialize other system services
including secondary RAM disk
start-up procedures complete
OS ready
______________________________________
Referring to FIG. 6 specifically, a control state 140 exists within the operating system boot loader to determine whether the operating system kernel image is present in ROM already or needs to be downloaded. If the operating system kernel image is to be downloaded, a transition is made to control state 142 wherein a request to receive an operating system download image is passed to a remote file server via the network interface 26. The first download block is received in control state 144. This first block includes the first 512 byte block of the operating system kernel image file. This block, and those that follow, are generally placed in the main memory 14 at a predefined location known to the operating system boot loader, though generally beginning at an address above the interrupt vector table. The data blocks consisting of the operating system kernel ".code" segment are received in control state 146. The ".data" segment is received and placed in main memory in control state 148. If the uninitialized data segment expand flag in rk.sub.-- flags, as determined from the kernel initialization structure received in control state 144, was not set, the full ".bss" segment is received in control state 150. If, however, the expand flag was set, a control state 152 is entered instead. Here, the OS boot loader directly allocates the required size of the ".bss" segment without requiring the segment to be actually downloaded. The ".bss" segment section header, received as part of the program header in control state 144, defines the desired size of the ".bss" segment. As this segment may be 80 to 100 kilobytes in length, depending on the configuration of the operating system kernel, a significant amount of time may be saved by expanding the ".bss" segment locally rather than requiring the segment to be downloaded. The ".bss" segment is then cleared. Control states 150, 152 both transition to a control state 154 to receive the operating system symbols segment for placement into main memory. Where the operating system is present in ROM, a transition is made from control state 140 to a control state 148' where the ".data" segment is loaded from ROM into main memory. A transition is then made to a control state 152'. In this state, the OS boot loader directly allocates the required size of the ".bss". The size of the ".bss" segment is determined from the operating system program header stored at the beginning of the ROM stored image of the operating system code segment. Again, since the ".bss" segment may be 80 to 100 kilobytes in length, depending on the configuration of the operating system kernel, a significant amount of ROM storage is saved by expanding the ".bss" segment by the function of the OS boot loader, rather than requiring an image to be stored in ROM. The RAM ".bss" segment is then cleared. Control state 152' transitions to a control state 154' to receive the operating system symbols segment for placement into main memory. State transitions from the control states 154 and 154' are made to the final OS program loader state 156. This final state prepares a pointer value to the kernel information structure and, from that structure, determines the entry point to the operating system kernel image for execution. A control state transition, transferring the kernel information structure pointer, is then made to the operating system kernel. A generalized control state 158 represents the initial initialization operations performed by the operating system kernel. These operations would include, for example, establishing the virtual memory management page tables and the kernel stack pointer. A transition is then made to a control state 160 that provides for the initialization of the kernel device drivers. The root file system is established with respect to the operating system kernel in this control state. On transition to a control state 162, the established root file system is mounted for standard access by the operating system kernel. A control state 164 generically represents the performance of all remaining operating system kernel internal initialization processes ending with a transition to a "ready" control state 166. The operating system is now ready for general use. FIG. 7 provides a control state transition diagram that illustrates the preferred modified operating system program load procedure of the present invention. A pseudo-code representation of this process is given in Table V.
TABLE V
______________________________________
OC Application Program Load Procedure
______________________________________
Call program loader with parameter indentifying
application program to execute
Program loader finds and reads header on program
If magic number = IMagic then
case: a.out format then
extra four bytes appended to program
header form pointer to the
stripped code segment
case: COFF format then
get physical address from pre-defined
header field
end.sub.-- case
force allocation of memory for text segment
to be at physical address for length
specified for code segment section
header; includes code segment within
the virtual execution space of the
program to prevent memory protection
faults
Else
allocate memory for code segment in the
transient program space for length
specified for code segment section
header
copy text segment from storage to allocated
space
End.sub.-- if
Allocate memory for data segment (.data and .bss
per sizes specified in section headers)
Copy initial data from storage to allocated .data
segment
Jump to code segment entry point
______________________________________
The operating system may receive requests to execute application programs from any number of different sources. These requests are processed to a control state 170 where the operating system program loader routine is called with an identification of the application program to be loaded and executed. In a control state 172, the operating system program loader, further operating through the pseudo-disk device driver, locates the requested program. The program header is read in a control state 174. Where the magic number is not set to the value of IMagic, a transition is made to a control state 176 that provides for the normal allocation of the process address space necessary for the execution of the requested application program. The program header, as obtained through control state 174, defines the amount of virtual address space required. In this control state, a call is made to a "get memory" kernel routine that operates to first allocate, then map the allocated memory into the virtual address space of the process. Table VI describes the preferred "get memory" kernel routine function call.
TABLE VI
______________________________________
Get Memory Kernel Routine
______________________________________
Synopsis: Obtain a fully qualified block of
memory for use by a process.
Output: OK or SYSERR
Syntax:
getmem(mblock, base, size, job, flags)
struct memblock *mblock;
/* pointer to
memory block
structure */
char *base; /* virtual memory address */
long size; /* byte size of memory
requested */
int job; /* job requesting memory */
int flags; /* access flags to be set */
______________________________________
The algorithm performed by the get memory kernel routine is as follows: 1. Calculate number of requested memory pages from "size" number of bytes. Dependant on the size of a memory page. 2. Get requested number of memory pages from memory free block list and attach to "mblock" memory block structure. Return SYSERR if all requested memory pages are not available. 3. Initialize pages attached to the "mblock" memory block structure. 4. Map these pages to the "job" process area by calling a kernel memory map routine (mem.sub.-- map()). If there is any error in mapping, return SYSERR after releasing the memory pages acquired in step 2. Otherwise return OK. The mapping of the allocated memory into the virtual address space of the process is performed specifically to establish the virtual memory protection mechanisms with respect to accesses within the allocated memory space by the execution of the application program. The preferred map memory kernel routine function call is described in Table VII.
TABLE VII
______________________________________
Map Memory Kernel Routine
______________________________________
Synopsis: Map a block of memory in to the
protected address space of a given
process address space.
Output: OK or SYSERR
Syntax:
mem.sub.-- map (reblock, job)
struct memblock *mblock;
/* memory block ptr */
int job; /* requesting job */
______________________________________
The "base" field of "mblock" memory block specifies the base or start of virtual address where memory is to be mapped to actual pages that are specified by the "plist" field, which is a list of actual pages. The preferred memory block structures are described in Table VIII.
TABLE VIII
______________________________________
Memory Block Structure
______________________________________
struct memblock {
/* memory block structure */
long base; /* start address (virtual) of
memory */
int count; /* number of pages of
memory */
int flags; /* access flags */
struct plist list;
/* actual page list */
};
struct plist { /* page list */
int head; /* head (pointer to first
page) of page list */
int tail; /* tail (pointer to last
page) of page list */
};
______________________________________
To accomplish the mapping, a correspondence is set up between the virtual addressed pages referenced by application programs, executing in their own virtual address spaces, and the physical memory pages that actually contain the required code or data. This mapping is generally machine dependent. However, the conventional function of the virtual memory management unit (MMU) is to take a virtual address and use it as an index to the page tables to find the corresponding physical address. The actual physical memory need not be contiguous. Thus, in control state 174, where the magic number of the program header is determined to match the value of IMagic, a transition is made to control state 178. The program header is examined in control state 178 to obtain the physical address of the code segment associated with the requested application program. transition is then made to control state 180 for the allocation of memory for the code segment. However, as this code segment is already present in memory as part of the stripped code segments area and is already properly initialized by definition, a modified call, represented by the dashed transition lines 181, is made directly to the memory mapping kernel routine. That is, in calling the "mem.sub.-- map()" function, the physical address of the stripped code segment is provided as the value of "mblock.base". An additional flag bit "Phys" is provided, or set, as part of the "mblock.flags" value to indicate that free space in the transient program area 66 memory need not be allocated in response to this call. Rather, the function of the memory map kernel routine is modified by the presence of the "Phys" flag bit to force mapping of a contiguous "mblock.count" number of pages of memory beginning at "mblock.base" into the context specific virtual address space of "job". In this manner, the stripped code segments area 78 is effectively included, as needed, in the transient program space of the address space portions 60, 130. Consequently, execution, indeed multiple executions, of this code segment are permitted fully consistent with the conventional memory protection function of the operating system kernel. Both control states 176, 180 transition to a control state 182 that provides for the allocation of memory to accommodate the program data segment, including the ".data", ".bss" and symbol table segments. Since the program data segment must be provided in the transient program area of main memory regardless of whether the corresponding application program is stripped of its code segment or not, the segment must be place in alterable memory. Therefore, in the control state 182, the get memory kernel routine is again called to allocate, initialize and map the required size of memory into the virtual address space of the process. On transition to a control state 184, the ".data" and symbols segments are copied from storage into a corresponding portion of the allocated data segment. A final control state transition is then made to control state 186 to initiate the execution of the application program within the processes virtual address space. This transition, though shown as a simple transition between control states 184, 186, is complex in that it must provide for the inclusion of the process in the execution scheduler of the operating system kernel as appropriate to schedule execution of the requested application program. However, in accordance with the preferred embodiments of the present invention, this control state transition is unaltered with respect to the conventional implementation of this function. Thus, a disk operating system and computer architecture, providing for program code segments to be reserved within the file system name space, has been described. Naturally, many modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that, within the scope of the appended claims, the invention may be practiced otherwise than is specifically described herein.
|
Same subclass Same class Consider this |
||||||||||