The Cost of SLIC

The decision to build a computer system with a high-level machine interface and a large portion of the operating system below this interface does have an associated cost. For the AS/400, this increased cost comes from the software development. Before we proceed, we need to look at why this is so.

SLIC is 3 million lines of trusted code. By trusted we mean the code must always do the right thing to protect the integrity and security of the system. Because SLIC is treated like the kernel of an operating system, we do not protect one SLIC component from another SLIC component. This approach is fairly typical: Most kernels are protected from corruption by any code outside the kernel, but within the kernel, all code is assumed to be trusted.

With a small kernel of, say, 100 thousand lines of code, it is fairly easy to thoroughly test the integrity of the kernel whenever changes are made. With 3 million lines of code, this testing becomes more difficult and more expensive to do. The approach we have used successfully in Rochester for many years is to maintain a rigorous development and testing environment and then to allow only a select group of people to work on the kernel. As a result, the only people who can generate code that is part of SLIC are the SLIC developers in Rochester — still a fairly large organization of people. But these developers operate in a highly structured development environment that guarantees all code is trusted. The negative side of this approach is that no one outside the SLIC development area ever generates code that runs in SLIC. Many times, outside organizations, including other IBM organizations, have requested the capability to write SLIC functions. In all cases, we have steadfastly refused. To let anyone write even a small part of SLIC could jeopardize the integrity of the entire system, and we will not let that happen. The consequences of this decision are that the availability of new SLIC functions is gated by the availability of SLIC programmers to do the work. We almost never can share code with anyone else in IBM, at least not at the SLIC level.

In Chapter 4, we look at the way in which HLL compilers generate the PowerPC code that runs under the MI. We will see that this code generation involves the use of a SLIC component known as the translator. Like everything else in SLIC, the translator is a trusted component, which means the translator also is trusted to always generate code that will never compromise the integrity or security of any other component. Translators, too, are only developed in the Rochester SLIC organization.

The good news is that all the SLIC functions work together as a whole. Because all of SLIC is developed under one roof, we achieve a level of consistency that can only be dreamed about in systems that use a piece-meal approach to development. Sharing common software parts across multiple operating systems may be a nice cost savings, but it can’t match the integration of function the AS/400 enjoys. Speaking of common parts, it is possible to incorporate some standard components without compromising consistency, as we will see in the next section.

SLIC Kernel Technologies

In the past, every kernel was unique to a particular operating system. There was little desire to build a kernel separate from an operating system, but that attitude began to change in the mid-1980s, when schools such as Carnegie-Mellon University began to study kernels that could be used for more than one operating system. Carnegie-Mellon defined a microkernel it called Mach. The Mach microkernel is a subset of a kernel, and it includes the common functions that most operating systems need.

If two or more operating systems are built on top of the same microkernel, it is possible to run those operating systems concurrently on the same processor. Furthermore, the operating systems can share resources and communicate with one another in a very efficient manner. In recent years, multiple operating systems running on a common microkernel have been called personalities.

Because SLIC was designed to be a new operating-system kernel, it made sense to include some of the technologies needed to support multiple personalities. Actually, much of this was in the original LIC. For example, a microkernel uses a message-based approach to dispatch work for a given operating system in the processor. This same message-based dispatching was used in the original System/38 and was carried forward into the AS/400. In Chapter 9, we examine this mechanism in detail.

At the time we were developing the SLIC, studies and proposals were being made in IBM to share operating-system components across all IBM systems that used the PowerPC processors. One of the leading proposals was to use the IBM microkernel (which was derived from the Mach microkernel) as the basis for this sharing. SLIC already had most of the technologies used in this microkernel, but the question was, “Should we build everything on top of the IBM microkernel?” The answer was pretty obvious. The only implementation being developed at the time was for a 32-bit microkernel. We would have to build a 64-bit version if we wanted to use it in the AS/400. The proposal to share software was also not firm, and there were still questions about scalability of the microkernel (How many users could it support?); so we decided not to build the SLIC on top of this microkernel. We did, however, put a group of people in place in Rochester to develop the 64-bit extensions to the IBM microkernel, so we could use it in the future. We also decided to include in SLIC the ability to support multiple operating-system personalities.

Adding support for other operating systems to the SLIC kernel didn’t make any sense if we didn’t plan to use it. Besides OS/400, what other operating system should we support? To some of us the answer was obvious, but we would need a little subterfuge to demonstrate how this support would work.