As a user: it's occasionally good to know how abstractions are implemented so that you can reason about them. For example, reasoning about performance and security both require understanding of underlying system.
As a system designer: Operating systems are always changing to adapt to new hardware and differing requirements: you may find yourself hacking on one at some point.
The OS is software that mediates the interactions between applications and hardware. It provides:
Abstraction: a common interface to many devices so that applications don't need to be written for specific devices, and don't need to worry about low-level details.
Virtualization: gives multiple applications the illusion that they have complete control over resources (such as the CPU, I/O devices, and memory) despite the fact that they are shared and limited.
Isolation: prevents untrusted applications from interfering with each other
Access control: allow untrusted applications to have access to resources in a controlled way.
We went through several revisions of a "soviet era keyboard" design. See the board images for more detail. Here are some key takeaways from our discussion:
This course is positioned between the architecture and the programmer. We're not going to do too much at the circuit design level, but it's important to realize that there are no "magic gnomes" ferrying the data from the keyboard to your program.
Peripherals (such as keyboards and mice, but we'll see later disk drives, etc) have some internal state; and are connected to the CPU over an I/O bus.
We left a few unresolved questions in our design:
We used tri-state buffers to effectively disconnect devices from the I/O bus when they are not in use. Who decides when a device is "in use"?
What happens to keystrokes while the keyboard is "disconnected"?
How does the software interact with the devices over the I/O bus?