File Management

From Soma-notes
Revision as of 13:17, 8 November 2007 by Polina Vinogradova (talk | contribs)
Jump to navigation Jump to search

These notes are not complete yet. A proper table of contents, formatting and the Device Drivers, Scheduling and Registry sections I will add a bit later today.


1. Pipelining

2. Startup to Shutdown

2.1 Startup

2.2 Shutdown

3. Signals, Interrupts and System Calls

4. Device Drivers

5. Scheduling

6. Registry


Pipelining

Pipelining is a strategy that allows even single-core CPUs to execute multiple instructions in parallel.

For example The following list of instructions is to be executed: Load Compare Store Branch

For each of the instructions, the following have to be performed: Fetch Decode Get operands Do operation Store result

Each of these operations may be done by different pieces of silicon. So, while load is decoded, compare may be fetched, etc.

How does the CPU know what this code is going to do next? It may execute likely instructions, or all possible next steps. This is known as speculative execution. The 'likely' instructions are ones that, for example, have been executed multiple times previously (the CPU has counters to keep track of the number of executions).

What is the most efficient execution strategy? It is difficult to tell without actually running the instruction. This is known as Feedback Direct Optimization. For example, due to this type of optimization, Java code may actually execute faster than the C++ version.

Pipelining causes context switching to become more expensive because every time a context switch occurs, it causes the entire pipeline to be flushed, thus a lot of the work the processor has done is lost.


Startup to Shutdown


Startup

1. BIOS is loaded BIOS used to be ROM. Now, it is just Flash, and is modifiable.

2. Device initialization For example, set all the bits in RAM to 0. All the hardware is put into sane state.

How does the BIOS know something is bootable? It follows the boot order. It starts with loading the first block.

3. Code is loaded from the boot device

4. This boot block loads the boot loader Here is where the switch is made to protected mode.

5. The boot loader loads the kernel

After this is done, the kernel repeats most of the same process. For example, it initializes the hardware again, since the BIOS may not have initialized it all properly.

In the kernel's initialization: - Devices, CPU and RAM are enumerated and initialized

- Interrupt tables are set up

- Mount the file system: the rest of the code the kernel has to run in stored in a file system. The first file system that is loaded is the fake or initial root file system. This may the the RD (RAM disk) that the boot loader loaded into memory. This first fs is necessary for the kernel to access other code and device drivers. Once, that is done, the real fs can be loaded.

What to do if a fs is not loaded? The kernel panics. We will talk more about this later.

- Switch control to user land. Start the process /sbin/init running.

It is important to separate mechanism from policy: policy is accessible in user space and easier to deal with.

On Unix machines, the init process does not do much itself because it has processes re-parented to it. So if init dies, the whole system goes down.

- The init process creates new processes (which is totally configurable), and has to load other binaries. So, the init runs some scripts that start processes running (newer init scripts do this in parallel). The ones to run on startup and shutdown are indicated with the first letter in the name of the process.

- What to do next? Schedule these processes. More on scheduling below. The info on the execution context (CPU state) is in the kernel structure task_struct.

At this stage some processes are listed that do not match any executables on disk. This is done to allow the CPU to perform some tasks asynchronously.

Note: The CPU's supervisor modes is a hardware feature The 'root user' is a software feature (this feature is needed so that the CPU knows which processes to listen to)

- Next, the login environment is created, and the user's privileges are set up


Shutdown

- Shutdown scripts are run. These send signals to processes to terminate. Specifically, the init process.


Signals, Interrupts and System Calls

Signals send messages between processes. These are sent by invoking the kernel, and thus the proper signal handler of the other process is used. All programs (processes) have signal handlers. It is possible to force them to ignore most signals, but not the kill signal. It has a special handler outside the library code included in most programs.

Interrupts, on the other hand, cause the CPU to go into supervisor mode to handle it.

System calls special instructions which cause a software interrupt.


Device Drivers

Scheduling

Registry