Page 338 - DCAP103_Principle of operating system
P. 338

Unit 11: Operating System Structure



            11.1.2 Kernel Layer                                                                   Notes
            Above the hardware abstraction layer is a layer that contains what Microsoft calls the kernel, as
            well as the device drivers. Some early documentation refers to the kernel as the “microkernel,”
            which it really never was because the memory manager, file system, and other major components
            resided in kernel space and ran in kernel mode from day one. The kernel is certainly not a
            microkernel now since virtually the entire operating system was put in kernel space starting
            with NT 4.0.
            In the unit on UNIX, we used the term “kernel” to mean everything running in kernel mode.
            In this unit, we will reserve the term “kernel” for the part labeled as such in Figure 11.2 and
            call the totality of the code running in kernel mode the “operating system.” Part of kernel (and
            much of the HAL) is permanently resident in main memory (i.e., is not paged). By adjusting its
            priority, it can control whether it can tolerate being preempted by I/O interrupts or not. Although
            a substantial fraction of the kernel is machine specific, most of it is nevertheless written in C,
            except where top performance overshadows all other concerns.
            The purpose of the kernel is to make the rest of the operating system completely independent
            of the hardware, and thus highly portable. It picks up where the HAL leaves off. It accesses
            the hardware via the HAL and builds upon the extremely low-level HAL services to construct
            higher-level abstractions. For example, the HAL has calls to associate interrupt service procedures
            with interrupts, and set their priorities, but does little else in this area. The kernel, in contrast,
            provides a complete mechanism for doing context switches. It properly saves all the CPU
            registers, changes the page tables, flushes the CPU cache, and so on, so that when it is done, the
            previously running thread has been saved in tables in memory. It then sets up the new thread’s
            memory map and loads its registers so the new thread can start running.
            The code for thread scheduling is also in the kernel. When it is time to see if a new thread
            can run, for example, after a quantum runs out or after an I/O interrupt completes, the kernel
            chooses the thread and does the context switch necessary to run it. From the point of view of
            the  rest  of  the  operating  system,  thread  switching  is  automatically  handled  by  lower  layers
            without any work on their part and in a portable way. The scheduling algorithm itself will be
            discussed later in this unit when we come to processes and threads.
            In addition to providing a higher-level abstraction of the hardware and handling thread switches,
            the kernel also has another key function: providing low-level support for two classes of objects:
            control objects and dispatcher objects. These objects are not the objects that user processes get
            handles to, but are internal objects upon which the executive builds the user objects.
            Control objects are those objects that control the system, including primitive process objects,
            interrupt objects, and two somewhat strange objects called DPC and APC. A DPC (Deferred
            Procedure Call)  object is used to split off the non-time-critical part of an interrupt service
            procedure from the time critical part. Generally, an interrupt service procedure saves a few volatile
            hardware registers associated with the interrupting I/O device so they do not get overwritten
            and re-enables the hardware, but saves the bulk of the processing for later.

            For example, after a key is struck, the keyboard interrupt service procedure reads the key code
            from a register and re-enables the keyboard interrupt, but does not need to process the key
            immediately, especially if something more important (i.e., higher priority) is currently going
            on. As long as the key is processed within about 100 msec, the user will be none the wiser.
            DPCs are also used for timer expirations and other activities whose actual processing need not
            be instantaneous. The DPC queue is the mechanism for remembering that there is more work
            to do later.




                                             LOVELY PROFESSIONAL UNIVERSITY                                   331
   333   334   335   336   337   338   339   340   341   342   343