根据已有的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.
