|
1 Introduction 2 Ground Rules Building a File System 3 File Systems 4 File Content Data Structure 5 Allocation Cluster Manager 6 Exceptions and Emancipation 7 Base Classes, Testing, and More 8 File Meta Data 9 Native File Class 10 Our File System 11 Allocation Table 12 File System Support Code 13 Initializing the File System 14 Contiguous Files 15 Rebuilding the File System 16 Native File System Support Methods 17 Lookups, Wildcards, and Unicode, Oh My 18 Finishing the File System Class The Init Program 19 Hardware Abstraction and UOS Architecture 20 Init Command Mode 21 Using Our File System 22 Hardware and Device Lists 23 Fun with Stores: Partitions 24 Fun with Stores: RAID 25 Fun with Stores: RAM Disks 26 Init wrap-up The Executive 27 Overview of The Executive 28 Starting the Kernel 29 The Kernel 30 Making a Store Bootable 31 The MMC 32 The HMC 33 Loading the components 34 Using the File Processor 35 Symbols and the SSC 36 The File Processor and Device Management 37 The File Processor and File System Management 38 Finishing Executive Startup Users and Security 39 Introduction to Users and Security 40 More Fun With Stores: File Heaps 41 File Heaps, part 2 42 SysUAF 43 TUser 44 SysUAF API Terminal I/O 45 Shells and UCL 46 UOS API, the Application Side 47 UOS API, the Executive Side 48 I/O Devices 49 Streams 50 Terminal Output Filters 51 The TTerminal Class 52 Handles 53 Putting it All Together 54 Getting Terminal Input 55 QIO 56 Cooking Terminal Input 57 Putting it all together, part 2 58 Quotas and I/O UCL 59 UCL Basics 60 Symbol Substitution 61 Command execution 62 Command execution, part 2 63 Command Abbreviation 64 ASTs 65 Expressions, Part 1 66 Expressions, Part 2: Support code 67 Expressions, part 3: Parsing 68 SYS_GETJPIW and SYS_TRNLNM 69 Expressions, part 4: Evaluation UCL Lexical Functions 70 PROCESS_SCAN 71 PROCESS_SCAN, Part 2 72 TProcess updates 73 Unicode revisted 74 Lexical functions: F$CONTEXT 75 Lexical functions: F$PID 76 Lexical Functions: F$CUNITS 77 Lexical Functions: F$CVSI and F$CVUI 78 UOS Date and Time Formatting 79 Lexical Functions: F$CVTIME 80 LIB_CVTIME 81 Date/Time Contexts 82 SYS_GETTIM, LIB_Get_Timestamp, SYS_ASCTIM, and LIB_SYS_ASCTIM 83 Lexical Functions: F$DELTA_TIME 84 Lexical functions: F$DEVICE 85 SYS_DEVICE_SCAN 86 Lexical functions: F$DIRECTORY 87 Lexical functions: F$EDIT and F$ELEMENT 88 Lexical functions: F$ENVIRONMENT 89 SYS_GETUAI 90 Lexical functions: F$EXTRACT and F$IDENTIFIER 91 LIB_FAO and LIB_FAOL 92 LIB_FAO and LIB_FAOL, part 2 93 Lexical functions: F$FAO 94 File Processing Structures 95 Lexical functions: F$FILE_ATTRIBUTES 96 SYS_DISPLAY 97 Lexical functions: F$GETDVI 98 Parse_GetDVI 99 GetDVI 100 GetDVI, part 2 101 GetDVI, part 3 102 Lexical functions: F$GETJPI 103 GETJPI 104 Lexical functions: F$GETSYI 105 GETSYI 106 Lexical functions: F$INTEGER, F$LENGTH, F$LOCATE, and F$MATCH_WILD 107 Lexical function: F$PARSE 108 FILESCAN 109 SYS_PARSE 110 Lexical Functions: F$MODE, F$PRIVILEGE, and F$PROCESS 111 File Lookup Service 112 Lexical Functions: F$SEARCH 113 SYS_SEARCH 114 F$SETPRV and SYS_SETPRV 115 Lexical Functions: F$STRING, F$TIME, and F$TYPE 116 More on symbols 117 Lexical Functions: F$TRNLNM 118 SYS_TRNLNM, Part 2 119 Lexical functions: F$UNIQUE, F$USER, and F$VERIFY 120 Lexical functions: F$MESSAGE 121 TUOS_File_Wrapper 122 OPEN, CLOSE, and READ system services UCL Commands 123 WRITE 124 Symbol assignment 125 The @ command 126 @ and EXIT 127 CRELNT system service 128 DELLNT system service 129 IF...THEN...ELSE 130 Comments, labels, and GOTO 131 GOSUB and RETURN 132 CALL, SUBROUTINE, and ENDSUBROUTINE 133 ON, SET {NO}ON, and error handling 134 INQUIRE 135 SYS_WRITE Service 136 OPEN 137 CLOSE 138 DELLNM system service 139 READ 140 Command Recall 141 RECALL 142 RUN 143 LIB_RUN 144 The Data Stream Interface 145 Preparing for execution 146 EOJ and LOGOUT 147 SYS_DELPROC and LIB_GET_FOREIGN CUSPs and utilities 148 The I/O Queue 149 Timers 150 Logging in, part one 151 Logging in, part 2 152 System configuration 153 SET NODE utility 154 UUI 155 SETTERM utility 156 SETTERM utility, part 2 157 SETTERM utility, part 3 158 AUTHORIZE utility 159 AUTHORIZE utility, UI 160 AUTHORIZE utility, Access Restrictions 161 AUTHORIZE utility, Part 4 162 AUTHORIZE utility, Reporting 163 AUTHORIZE utility, Part 6 164 Authentication 165 Hashlib 166 Authenticate, Part 7 167 Logging in, part 3 168 DAY_OF_WEEK, CVT_FROM_INTERNAL_TIME, and SPAWN 169 DAY_OF_WEEK and CVT_FROM_INTERNAL_TIME 170 LIB_SPAWN 171 CREPRC 172 CREPRC, Part 2 173 COPY 174 COPY, part 2 175 COPY, part 3 176 COPY, part 4 177 LIB_Get_Default_File_Protection and LIB_Substitute_Wildcards 178 CREATESTREAM, STREAMNAME, and Set_Contiguous 179 Help Files 180 LBR Services 181 LBR Services, Part 2 182 LIBRARY utility 183 LIBRARY utility, Part 2 184 FS Services 185 FS Services, Part 2 186 Implementing Help 187 HELP 188 HELP, Part 2 189 DMG_Get_Key and LIB_Put_Formatted_Output 190 LIBRARY utility, Part 3 191 Shutting Down UOS 192 SHUTDOWN 193 WAIT 194 SETIMR 195 WAITFR and Scheduling 196 REPLY, OPCOM, and Mailboxes 197 REPLY utility 198 Mailboxes 199 BRKTHRU 200 OPCOM 201 Mailbox Services 202 Mailboxes, Part 2 203 DEFINE 204 CRELNM 205 DISABLE 206 STOP 207 OPCCRASH and SHUTDOWN 208 APPEND Glossary/Index Downloads |
Overview of The Executive
The Component Approach Sometimes the layering approach is referred to as a "stack". I don't use that term for this approach, as it might lead to some confusion with the LIFO data structure of the same name. Instead, we will use the above terminology for this architecture - layered. However, we cannot take this same approach with the executive. This is because the various components that make up the executive all rely on each other. There is no hierarchical structure here other than that the kernel is at the center, not unlike a spider at the center of a web. The components are marshalled (loaded and setup) by the kernel. Once they are running, however, they all operate semi-autonomously. Each one has a specific scope of responsibility and they all work together to serve up the executive's functionality. The following diagram helps to illustrate the difference between these two architectures.
Because of this organization, we can't approach the subject as we approached the file system. Rather, we will look at specific operations and follow the trail through the various components that are necessary to accomplish the task. We will only expose enough of each component as is necessary to accomplish the operation. In this way, we can explore various aspects of UOS without getting lost in the complexity. As we complete our discussions of various operations, we will release new binaries and sources (and documentation). Be warned - it may take us a great many articles to address even the simpler operations. What we call the UOS "executive" is equivalent to what is called the "kernel" in most operating systems. "Executive" is short for "Exceutive Monitor", which is what they used to called kernels back in the dark ages of computing. We use this term to avoid confusion with the central component in the executive, which we call the Kernel. The executive is layered on top of the HAL, which is used to access the specific hardware of whatever computer UOS is running on (just as does Init). The kernel provides two main services: it marshals the rest of the executive components, and it provides the Application Program Interface (API) for all programs that run on UOS. That is, the kernel is the single point of access to the functionality of the executive for all software that is outside of the executive. Within the executive, the various components ask the kernel for the instances of the other components and then directly call each other. Here is a brief list of executive components:
Let's review the reason why we use all these components in the first place. After all, couldn't we write the executive as a single software module? Yes, we could - and many operating system kernels are written this way. The reason we are using the component approach is because it makes it easier for people to supply updated or new components for UOS. For instance, perhaps some real-world use of UOS requires a high-speed memory management unit that outperforms the standard one included in public distributions. You may ask, "why not just use the high-speed component as the standard one?" Recall that software is a matter of trade-offs. Increasing the performance may have downsides such as a larger disk and/or RAM footprint. Or the component may be a commerical implementation that you have to pay for. Even ignoring alternate versions of components, there is the need to provide updates for UOS. If the entire executive has to be replaced on an update, that requires a reboot of the system. However, if individual components can be replaced, it is possible to update the system without requiring a reboot. This is extremely important on high-availability systems where downtime has to be minimized. Maybe it cannot be completely eliminated - but we want to achieve as close to 100% uptime as possible. Finally, writing the executive in components forces us to decouple things. Modular programming is simply good programming practice, but it is extremely easy to introduce pathological coupling unless the modularization is enforced by our design. In fact, it is this (almost inevitable) coupling that makes a single-module executive updatable only via reboots.
UOS software responsibility philosophy
The HAL and device drivers provide the physical hardware interfacing and abstraction for the use of UOS. The executive provides the core OS functionality. The CUSPs provide the interface between the executive and the user. The executive is accessed solely via a programming interface and contains no direct support for user interaction. In terms of I/O, it simply sends commands to the HAL based on requests made by programs. As can be inferred from the above diagram, requests come from higher layers to lower layers. However, there are three cases where the executive calls "up" to a higher layer.
This should make it clear where any given functionality belongs. We must always ask ourselves "is this a feature that should exist in the executive, or in a CUSP?" The only things that should go into the executive are things that can only go in the executive. If the functionality can go in a CUSP, it should. Security features, for instance, are implemented largely in the executive because we cannot rely on programs to be well-behaved. However, the actual login process is largely handled by the Login program, which queries the user for things like a user name and password. This input is passed to the executive to actually associate the user with the object being logged in (perhaps a terminal or a spawned process). Knowing this philosophy means we won't be including, for instance, a user name prompt inside the executive. Now that we have discussed the architecture and philosophy of UOS, the next several articles will deal with the process of starting up the Executive. The next article will look at the first part of the kernel startup code. |
