We used some Linux tools to explore processes and system calls. You are enouraged to play with these on your own, and to look into the Linux system calls (or system calls for your favorite operating system).
ps -A: list all running processes. -A instructs ps to output all running processes, instead of just subprocesses started from the running terminal
the /proc filesystem is a way to examine data from the PCBs of the currently running processes. Note that there are no on-disk files corresponding to the /proc filesystem; rather the kernel responds to read requests to files in this directory by returning data read from the PCBs
the strace command runs a program as a subprocess and prints out all of the system calls that the subprocess executes. We straced the "true" program (a trivial program that does nothing and returns true) and "bash" (a shell). To strace bash interactively we ran "strace bash 2> log.txt" in one terminal window, and "tail -f log.txt" in another. The first command redirects the output from strace into the file log.txt, the second displays log.txt as it changes.
We noted some interesting facts about the linux system call interface:
we noted the exit system call which is used to terminate the currently running process, and the kill system call which sends a signal to another running process. Processes can register signal handlers (which are similar to interrupt handlers in the kernel); signals cause the process to jump to the signal handler.
(important for the homework) Unix exit codes are integers that the parent process can use to determine how a process exited. By convention, 0 indicates success, and a non-zero value indicates an error. In the shell, you can see the exit code of the most recent process by using the variable "$?". For example:
> true; echo $?
0
> false; echo $?
1Linux uses read and write system calls to special files to perform many tasks, including communicating with devices and performing input and output on the terminal
We noted a few alternative designs for an operating system:
monolithic kernel: The kernel has a broad, high-level interface and performs many functions with the privilege bit set. For example, device drivers are linked directly into the kernel; the system call handler would jump to a disk driver, for example. A monolithic kernel has code for all of the operating system services
microkernel: The kernel has a very narrow interface, and does not communicate with devices. Drivers run in their own processes; to perform I/O processes use system calls to initiate inter-process communication (IPC) with driver processes. Driver processes have the physical addresses corresponding to memory-mapped devices mapped into their virtual address spaces. A microkernel provides only inter-process communication and access control
virtual machine hypervisor: In a virtual machine (VM), "Processes" are themselves fully-fledged operating systems, and the hypervisor provides them a virtualized interface to the hardware. System calls are redirected to the system call handlers of the guest OS.
Thus far when discussing time-sharing between processes, we've simply said that when it is time to switch processes, the operating system selects a new process and then runs it. The details of "when it is time" and which process to select can have major impacts on system behavior.
We would like a scheduler that satisfies the following criteria:
We discussed the following algorithms: - First-come, first-served (FCFS): whenever a process becomes ready, it is placed at the tail of a queue. Whenever a process relinquishes the CPU, a new process is taken from the head of the queue and scheduled. - Pros: simple, fair (no process starves). - Cons: I/O bound and CPU/bound processes are treated the same, so waiting time, responsiveness, priority and predictability can be poor.