Lecture 5 - Process Management
You essentially want a system where every process has a projection in the kernel:
The thing here is that it requires good programmer discipline. You really need to restrict access where needed. If one user process happens to have to these kernel-level things, then it can screw things up.
Could we maybe do something smarter? We should force abstraction layers so that we have privacy between functions. The first system that did this was Dijkstra's 'The Operating System'. It's built in layers where each layer contributed something.
Some notes on the levels:
- Why is IO management above memory management? Because the IO program should complain to the OS about this. In case the IO device seems to fail.
What did the OS do to enforce these barriers? Nothing, at least back in the day. But this idea gave programmers the discipline it needed to enforce these boundaries.
What else might we do? For lab 2 you need to install minix
on a PC, but you'd probably want to do it on a VM.
The System360 was expensive, so which OS do you boot in the morning? IBM introduced VM-370, which hosted guest programs such that they thought they were on hardware. Instead they got this:
All the OS instances were up top, but we don't want chaos. Each user process:
- Will do their own thing
- Once it tries to do something with privilege's, cause an
EXCEPTION
- VM370 sees the exception, notes it, and returns from interrupt.
- VM370's timer goes off, for the OS360 guest. Do the thing the guest wanted, then return from interrupt.
The cool thing (as the right of the figure shows) is that VM370 can be its own host.
But there's a catch! Time is gonna behave really weirdly for the guest OS's since there are so many timers, interrupts, and handlers going on. Another possible issue is you don't want to load a virus that can figure out if they are on a VM. They can notice:
- If time is weird (as we've discussed)
- If it's specifically a Windows VM and there's no junk on the desktop, then it's probably a windows VM.
There are a lot of things in the OS that really don't require privilege:
- Deciding what a file does doesn't really matter
- Accessing (R/W/X) does
There's a distinct difference between mechanism and a policy:
- Ex: A PHD program has limits on 7 years of staying.
- The mechanism is giving the degree or kicking people out.
Most grad schools cut off funding as your years go on, to incentivize you to get out at the wallet.
For the OS, it's the same idea:
But the problem with this was that most of the time spent on the CPU was spent copying data and sending messages. But you can reduce it, and we can nowadays afford these luxuries in exchange for robustness.
Minix
For minix
especially it has the following structure:
Here the only pieces required are:
- The kernel: communication, protection, message passing
- The clock: an independent process that runs in kernel mode to keep timers.
- The system: an API that allows drivers and user processes to interact with the kernel.
Above this we have: - Device Tasks: How to operate your disk (we need to obviously know how the manufacturer intends to operate it)
- System Servers: manage files, memery manager, etc.. If one system dies try to resurrect it.
- User Level:
init() -> main() ...
cat
cat
sends a message to the filesystem to ask the disk which asks the system task to turn on the disk and read it. After a while a disk interrupt happens, handled by the kernel, which generates a message to the disk task and get a copy of the data. Then it propagates back up to get the operation.
In a few weeks you'll make a device driver. Are you sure the driver won't have bugs? Don't worry! The system is designed to defend itself against these bugs in the higher levels.