USIX OS

The USIX Operating System is designed to provide source and binary compatibility with SVR4/386 while offering guaranteed response time to interrupts in real-time applications, multiprocessor kernel architecture, better resource utilization, a more robust file system and the ability to dynamically extend the kernel without re-linking.

The Base Package consists of the kernel configured for three or unlimited number of users, installation manual and programs, device drivers for the most common hardware configurations and several USIX utilities.

In addition, a set of basic GNU utilities (some modified for better compatibility with SVR4) is provided with the package free of charge.

The USIX operating system was developed by the team of the Institute of Electronic Control Machines (INEUM). USIX supports generally accepted international standards and conventions (POSIX 1003.1b-1993, SVID, X11, etc.). The USIX architecture is based on the concept of a microkernel, which performs only the most necessary functions: memory management, process planning and interaction, handling system calls, time service. Drivers, file system and other system functions are implemented as special server processes.

USIX supports the virtual organization of process memory based on the concept of memory objects, regions, and segments. The USIX kernel is independent of the specific type of file system and the format for storing data on disk, so it is possible to create file servers for any file structures. USIX implements the 's6' file structure server, which is the main server and has a number of features that are not available on UNIX systems. In addition, USIX supports a number of traditional file structures ('s5', 'dos', 'cdfs').

Security features of the USIX system currently ensure compliance with security level C2 and include discretionary access control, identification and authentication mechanism, registration and accounting tools.

USIX supports a complete set of TCP/IP protocols for working both in an Ethernet-based local area network, and via SLIP or PPP over a serial channel.

The user interface is implemented in the form of libraries TLI and Socket. The standard set of network utilities is supported, including telnet, rlogin, rsh, tftp, ftp, etc., as well as the NFS network file system and various types of network controllers.

USIX uses X Windows as the GUI (currently MIT version 6).

The C programming system includes the following GNU components:

• compiler
• assembler
• static and shared libraries
• linker
• debugger

The parallel programming system is implemented at the user level in the form of a set of library programs using the thread mechanism in accordance with the POSIX 1003.1c standard. To create information systems based on USIX can be used relational database management systems Oracle and Linter.

Features

• Fully pre-emptible Kernel
• Multiprocessing Kernel
• Robust File System
• Small Kernel
• Dynamically Loadable Device Drivers
• Dynamic I/O Buffer
• Swap Space Allocated as a File, not as a Partition
• Server Processes with ability to 'promote' functions to kernel memory address space

Benefits

• Guaranteed response time makes the system suitable for time-critical applications.
• Prevents obsolescence by permitting expansion of existing hardware.
• Gives better scalebility than systems based on patches applied to single-CPU kernels.
• Prevents corruption of the file system due to unexpected power failure or other improper system shutdown.
• Gives better performance in systems with limited RAM or disk space.
• Permits application programmers to develop device drivers, file systems and otherwise extend the kernel without access to kernel source code.

System Concepts

The UNIX Operating System has proven its value throughout its more than 20-year history. Portability, a good development environment, connectivity and a reasonably high degree of API compatibility between platforms have all contributed to assuring UNIX's permanent place in the computer industry.

In spite of many advantages, UNIX's market penetration has been historically less than satisfactory.

Some of the reasons must be attributed to marketing and political errors made by the companies primarily responsible for providing the UNIX technology. Others are related to technical deficiencies found in virtually all existing versions. System Six, Inc. has designed the USIX Operating System to solve the persistent weaknesses afflicting UNIX-like environments and to provide technological extensions enhancing inherent strengths of this powerful and flexible computing environment.

Compatibility

One of the most important features of UNIX is the portability of application programs between different hardware platforms and implementations of the OS. System V is the dominant force in today's UNIX market. In spite of this, most UNIX clones that are not based on the USL license make only a limited effort to support source compatibility, and almost no effort at all to provide binary compatibility with System V derivatives. Some of the existing systems make an impression of having implemented a subset of the POSIX standard. Most such implementations only satisfy minimum requirements to superficially qualify for government purchasing. One of the main design objectives of USIX was to provide 100% binary compatibility with the System V.4/386 kernel. We believe that computer users have seen too many 'white elephants', and have ported their software to enough variants of UNIX to be willing to accept yet another incompatible system.

Shrink-wrapped programs not requiring kernel-linked device drivers running currently on System V.4/386, will execute on USIX without recompilation or any modifications, in spite of the fact that USIX is internally totally different from SVR4 and is not based on the USL license.

Multi-Processor Support

The standard System V.4 and its derivatives were initially designed long before multi-CPU architectures became popular. Because of the size and the high level of complexity of the SVR4 kernel, attempts to modify the kernel to support multi-CPU architectures have been only partially successful. While some of the hardware manufacturers have achieved a relatively high level of efficiency in their implementations, it has always been at the expense of portability and at tremendous development cost. The only portable adaptation currently marketed (SCO MP), exhibits compromises in performance, especially in the areas of disk access, other I/O buffer access, and networking.

All of these attempts, while often well executed and impressive in themselves, do not address the basic underlying weakness of System V: a single threaded, non-interruptable kernel operating as one huge critical region.

USIX was implemented from the beginning as a multi-CPU based kernel (even though it is perfectly comfortable executing on a single-CPU computer). It is fully pre-emptible and supports symmetric MP architectures at all levels, from the kernel internals, through device drivers, to higher-level functions such as TCP/IP. It therefore provides a much better and more linear scaleability than systems relying on patches to a single-CPU kernel.

Real Time Features

The System V.4 specification defines a number of real-time features not available in earlier releases of UNIX. The most important of those features are Real-Time Priorities, Asynchronous (or multiplexed) I/O and Real-Time Timers.

The fact that these features are defined does not, however, make the V.4 a real time kernel. The critical necessity for real-time applications is the predictability of the response time to interrupts. Adding a few pre-emption points (as in SVR4) improves this response time, but it does not make it predictable. The SVR4 kernel is still a typical time-sharing kernel, with a few preemption windows in the otherwise monolithic critical region. Most of the kernel's functions are not bound, making it impossible for a higher priority processes to interrupt the kernel in a pre-defined time. In this respect, the USIX architecture is diametrically opposed to that of System V. The USIX kernel can almost always be interrupted. Critical regions (necessary in all operating systems to protect the integrity of certain operations such as setting of semaphores) are very short, very few and well defined. The response time is therefore fully deterministic.

Real-Time priorities are the priority levels higher than that of the kernel. Processes executing at these priorities can be pre-empted only by processes with an even higher priority. No time-sharing of processes executing at the same priority is permitted (processes execute until they terminate, or otherwise voluntarily give up the control of the CPU). Such processes are particularly useful as server-class programs, described later.

Asynchronous I/O permits a single process to initiate several otherwise blocking I/O requests simultaneously, and to continue execution while waiting for the completion of these requests. This method spares the system context switches that would be necessary if multiple processes were used to service one I/O request each, and allows easy consolidation into one process of data incoming from several sources.

In addition, the USIX kernel was designed with the goal of providing the shortest possible interrupt latency, context switching time, semaphore shuffling time, and deadlock breaking time (deadlocks occur if a higher priority task suspends a lower priority task that has set a semaphore needed by the higher priority task).

Servers

In order to allow easy kernel extensions, System Six implemented in USIX a new class of processes. Known as 'servers', these processes execute in user address space, but have managed and controlled access to the I/O subsystem and certain other kernel resources.

Servers can overlap their memory objects with objects from other processes and from the kernel, thus eliminating delays associated with copying of data between different address spaces. In addition, they can 'mount' themselves on directory entries, permitting other processes to issue I/O commands normally used on files and devices, and having these commands intercepted, interpreted, and processed by the server. The basic principle of several processes communicating with each other through pseudo files is similar to FIFOs and STREAMS. The difference between those mechanisms and USIX servers is that servers execute as user space processes, and permit not only open, read, write, lseek and close functions, but also ioctl and other control calls.

The main purpose of the servers is to allow easy programming of device drivers and new file systems (including network file systems) without the necessity of re-linking the kernel. This method has several major advantages over the usual kernel-linked facilities: servers are dynamically loadable (do not occupy RAM while they are not needed), can be developed using the same 'C' libraries as normal application programs (kernel-linkable routines require a special, limited library), are much less dangerous to implement (much less likely to crash the kernel), and are much easier to develop (on average, 5 - 10 times shorter development time compared to a traditional device driver).

In order to avoid the penalty of an additional context switch, parts of servers can be placed at run-time in the kernel address space. This permits fast service of interrupts at hardware priority, but still allows software priority for the rest of the driver.

Several servers are used in USIX by default to provide some of the basic services: file system emulation, serial terminal and console I/O and several other device drivers. Some facilities (such as STREAMS) are available both as servers and as linkable kernel modules. Other possible applications include database and screen windowing servers.

Disk I/O Subsystem

The USIX file system has been designed to provide enhanced reliability and user security. Several copies of all vital structures are maintained throughout the disk to lower the chance of a catastrophic data loss. Directories support additional data needed for higher user security levels. Although the file system is physically different from the standard s5 or ffs, the file system server provides total emulation of s5. This means that even older programs that open directories as if they were ordinary files instead of using system calls, will function correctly.

Three new features will be noticeable to all users:

• There is no need to define a separate swap file system during installation. An ordinary file is used for swapping (temporary storage of data and programs that do not fit in RAM). This file is created automatically during installation with a pre-defined length, but will be dynamically extended (as do other UNIX files) as needed. This prevents 'OUT OF SWAP AREA' errors and necessity of re-installing the entire system from scratch in case the initially allocated swap file system is too small.
• There are several synchronization levels (buffering) available:
  • Full synchronization (no buffering at all) is used only for the applications demanding absolutely no data loss under any circumstances. The penalty is poor disk I/O efficiency.
  • No synchronization (all functions are fully buffered) is the mode native to UNIX. It is efficient, but a power failure will likely cause not only loss of data currently being written to disk, but also a possible corruption of the file system. fsck must be executed after the power is restored (a scary procedure for an end-user).
  • Partial synchronization, where all ordinary writes-to-file are buffered, but any operation changing the file system structure is performed immediately. This mode provides almost as high efficiency as full synchronization, but is quite immune to any file system damage. There is no need to run fsck after power failure.
• All of the RAM not used by processes or the kernel is automatically used as disk buffers, providing the best possible utilization of RAM and an optimized disk I/O performance.

All disk accesses (data file access, loading of programs, swapping) are performed by the same basic virtual memory mechanism, making possible efficient head movement scheduling (the elevator algorithm).

Dynamic Kernel Parameters

A traditional UNIX kernel is configured by changing various parameters in mtune or stune files, and re-linking. After re-linking, the system has to be shutdown and re-started. This is a cumbersome and dangerous procedure.

Most kernel parameters in USIX can be dynamically changed at almost any time, by execution of a simple program. This permits the kernel to be re-configured based on actual demands of the moment. In addition, multiple debugging features, such as trapping of system calls and interrupts, can be initiated by executing a command to simplify debugging of device drivers, servers and application programs. Trapping of NULL page references can also be dynamically enabled or disabled.

Size and RAM demands

System V has been growing for many years, not only in terms of features but also in terms of RAM and disk space demands. A standard distribution of a minimum configuration of System V requires today more than 18 diskettes. The system cannot even be installed with less than 4 MB RAM, and once it is installed, the kernel occupies more than 1.5 MB of RAM. In real life, a minimum of 8 MB of RAM is needed (or 16 MB if X-Windows are used).

USIX is much smaller in many respects. It will boot from a single floppy, which also contains several of the most important utilities such as ls, cp, mv, mount, etc. It will run with several users logged on with as little as 2 MB of RAM.

Besides saving your hardware budget and making the system faster, the smaller size also makes maintenance, bug fixes, extensions and updates much simpler.