根据已有的Compiler框架，继续实现几个复杂的OS特性的功能，支持更多的语法。
Project Background
A central program for running a vast majority of software is an operating system. The operating system can abstract the underlying hardware upon which these other, “user-level” programs run, to provide them with uniform access to the hardware, along with providing many other services, from security through process isolation to sharing of hardware through multiplexing, all facilitated through common operating system features such as schedulers or virtual memory. Unfortunately, because of the vast number of services provided by operating systems and the complexity of implementing those services, existing operating systems can be difficult to reason about or use as a basis for exploration of new ideas and research.
Another complicating factor for operating systems running on processors made by Intel is the requirement for backwards compatibility. For many years, Intel processors were 32-bit systems using the so-called “x86” instruction set architecture (ISA), and, as a consequence, a large amount of software has been written for such processors. Within the past decade, then, as processors have begun switching to 64-bit, backwards compatibility of the new “x86-64” ISA with existing x86 programs has been a large goal, introducing complexity to operating systems needing to manage these processors.
In light of these problems with modern operating systems, this Compliler project will seek to implement a new operating system kernel from the ground up with goals of mitigating those issues. That is, it will be compatible with only x86-64 based Intel processors, and it will be designed and implemented in such a way as to allow for relatively easy reasoning about it and relatively easy extension, with the goal, from the reasoning angle, that operating system can be used in future formal verification proofs.
In addition, there is one area in which further research and extension can be done immediately. For the most part, most current operating systems mediate all interactions between user programs and hardware devices, introducing copying, security checking, and other overheads. One way to get around this is by providing devices directly to user programs in user space, completely eliminating the need for kernel mediation in many situations. Some prior work has been done with network interface cards and storage controllers, so as a first step for extension using this operating system as a basis, the network interface card behavior will be reimplemented. However, this operating system will also be designed such that the user-level hardware access can be generalized to any new hardware device.
Overall, the goal of the Compliler operating system kernel is to provide a well-designed basis for continued operating system development and reasoning, with a first extension of development being the exposure of network interface cards, in an API generalizable to other devices in the future, to user-space programs.
Users
Continuing Researchers
The first users of the system will be users of the code itself, doing further work and research to extend it. They will require that all of the code be designed and implemented in a relatively clean and extensible way, so that it is possible to continue to make use of it. In addition, part of the future research will be for completing formal verification proofs about the operating system. This necessitates the design of the system be clean so that it will be suited for the verification, as an increase in design complexity would increase proof complexity.
Programmers Desiring User-Space Device Access
Other users of the system are programmers wishing to make use of hardware devices exposed to user-space. These are users who want to take advantage of the extension mentioned in the Project Background, which will provide devices into user-space. This has the potential to speed up the access to many devices, so this project may attract programmers who wish to increase the performance of their programs by making use of the feature.
Features to Be Implemented
Functional Features
Intel x86-64 Compatibility
Description
The Compliler operating system will run on 64-bit Intel x86-64 based processors. Note that the operating system will not have to be compatible with pure x86 programs.
Relevance to Users
This will be relevant to all users of the system. Anyone who wishes to work with, run, or program for the system will need to know on which compatible processors it can be run.
Process Scheduling
Description
To run user processes, there must be a way to give them access to the CPU so they can actually execute their instructions, necessitating services from the operating system to schedule which ones will be run. Compliler will provide such services, but the exact details of algorithmic implementation have no requirements at this point.
Relevance to Users
This will be relevant to all users of the system. For any user, including programmers taking advantage of the network card extensions, to run a process requires executing the process’s instructions, which requires the process to be scheduled to run by the operating system.
Virtual Memory
Description
A virtual memory system will be implemented for Compliler, such that different processes running on the system each have their own “virtual address space.” This will help ensure isolation between processes so that they cannot illegally access memory that is not their own, preventing errors in user programs and in the operating system itself.
Relevance to Users
This feature has indirect relevance to all users of the system in that it will prevent any “misbehaving’ processes from crashing or causing errors in other programs or the system itself. Additionally, it is required for the network interface card extensions of Compliler, relevant to the programmers wishing to make use of that feature.
Direct Control of a Network Interface Card by a Process
Description
For Compliler, an API will be provided that allows any user process to gain control of a standard network interface card attached to the system, allowing it to interact from user-space with the network.
Relevance to Users
This will mostly be relevant to programmers wishing to make use of the NIC device extensions, in that it is the first step towards providing user space access to NICs.
Developer API for Interacting with Network Interface Card
Description
This requirement works in tandem with the above requirement. For after a process can gain control of a NIC, Compliler will provide an API for interacting with the network from user-space, namely through a library version of a TCP/IP stack.
Relevance to Users
This will mostly be relevant to programmers wishing to make use of the NIC device extensions, in that it is the requirement which will fully allow their programs to interact with the network from user-space.
Benchmarking Program
Description
A user-space application will be provided to test network performance. This will serve as a way to benchmark the Compliler system against existing systems. The measurable metric will most likely be throughput of requests per second handled by a simple web server. The goal is to compare favorably to existing systems considering the relative maturity of the project.
Relevance to Users
The benchmark utility will be relevant to anyone interested in the experimental success of the project. This includes the original team and anyone judging the future potential of this operating system as a research platform.
Non-Functional Features
Well-Understood Security Model
Description
Security is a vast topic, particularly when it comes to operating systems, but the security implications of the design and implementation of the operating system should be well understood. This is particularly important when it comes to the user-space access to the network interface cards. Because the kernel will no longer lie between processes and the NICs, it is possible for processes to freely access the data of others. There does exist specialized NIC hardware which can prevent these issues by itself isolating processes, but providing support for these devices is much too far outside the scope of this project. Until a time in the future when that hardware can be more easily be accommodated in the system, the security implications of allowing unmonitored access to devices must be well-understood and well-documented.
Relevance to Users
This will be relevant to all users. Continuing researchers must be aware of the limitations in the system to correct them later. Programmers for the system must be aware of the security implications of writing for the system.
Extensibility
Description
While Compliler will be developed for a specific processor architecture and with a specific set of hardware components in mind, the operating system must be designed and documented such that the techniques used could be applied to add other hardware devices relatively easily.
Relevance to Users
This is mostly relevant to continuing researchers. They will be concerned with actually implementing the extensions at later times.
Efficiency
Description
The primary purpose of exposing I/O devices to user-level processes is to reduce the overhead caused by making multiple I/O calls that require the processor to switch to kernel mode. Efficiency will be tested using the Benchmarking Program described above.
Relevance to Users
This will mostly be relevant to programmers wishing to make use of the user-space device extensions, as they will hope for their programs to be more efficient by making use of the feature.
Licensing
Description
Any existing open source code that is integrated into the operating system, to reduce what needs to be done from scratch to save time, must not be copyrighted under the GNU General Public License.
Relevance to Users
This is almost entirely relevant to the continuing researchers, in that it dictates with what additional code they might eventually be working.
Features Not to Be Implemented
Paging
Compliler will not require its memory to be paged, that is, swapped to external storage. The computing system will be limited by its physical RAM without the ability to present it as extended using swap space as in many other operating systems. No design choices will be made that will prohibit this feature from being implemented later.
File System Support
Compliler will not provide file system support. That is, it will not provide a way to save files on external storage. Virtual file system support, such as providing access to devices through a file-like interface, will also not be supported. No design choices will be made that will prohibit this feature from being implemented later.