Sample-12 - SEC 12.2 867 12.3 IMPLEMENTATION Turning away from the user and system call interfaces let us now take a look at how to implement an

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: SEC. 12.2 867 12.3 IMPLEMENTATION Turning away from the user and system call interfaces, let us now take a look at how to implement an operating system. In the next eight sections we will ex- amine some general conceptual issues relating to implementation strategies. After that we will look at some low-level techniques that are often helpful. 12.3.1 System Structure Probably the first decision the implementers have to make is what the system structure should be. We examined the main possibilities in Sec. 1.7, but will review them here. An unstructured monolithic design is really not a good idea, except maybe for a tiny operating system in, say, a refrigerator, but even there it is arguable. Layered Systems A reasonable approach that has been well established over the years is a lay- ered system. Dijkstra’s THE system (Fig. 1-25) was the first layered operating system. UNIX (Fig. 10-3) and Windows 2000 (Fig. 11-7) also have a layered structure, but the layering in both of them is more a way of trying to describe the system than a real guiding principle that was used in building the system. For a new system, designers choosing to go this route should first very care- fully choose the layers and define the functionality of each one. The bottom layer should always try to hide the worst idiosyncracies of the hardware, as the HAL does in Fig. 11-7. Probably the next layer should handle interrupts, context switching, and the MMU, so above this level, the code is mostly machine independent. Above this, different designers will have different tastes (and biases). One possibility is to have layer 3 manage threads, including scheduling and interthread synchronization, as shown in Fig. 12-1. The idea here is that start- ing at layer 4 we have proper threads that are scheduled normally and synchronize using a standard mechanism (e.g., mutexes). In layer 4 we might find the device drivers, each one running as a separate thread, with its own state, program counter, registers, etc., possibly (but not neces- sarily) within the kernel address space. Such a design can greatly simplify the I/O structure because when an interrupt occurs, it can be converted into an unlock on a mutex and a call to the scheduler to (potentially) schedule the newly readied thread that was blocked on the mutex. MINIX uses this approach, but in UNIX, Linux, and Windows 2000, the interrupt handlers run in a kind of no-man’s land, rather than as proper threads that can be scheduled, suspended, etc. Since a huge amount of the complexity of any operating system is in the I/O, any technique for making it more tractable and encapsulated is worth considering. Above layer 4, we would expect to find virtual memory, one or more file 868 OPERATING SYSTEM DESIGN CHAP. 12 Interrupt handling, context switching, MMU Hide the low-level hardware Virtual memory Threads, thread scheduling, thread synchronization 1 2 3 4 5 Driver 1 Driver n ......
View Full Document

This note was uploaded on 05/20/2011 for the course COP 4600 taught by Professor Yavuz-kahveci during the Spring '07 term at University of Florida.

Page1 / 16

Sample-12 - SEC 12.2 867 12.3 IMPLEMENTATION Turning away from the user and system call interfaces let us now take a look at how to implement an

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online