Page 336 - DCAP103_Principle of operating system
P. 336

Unit 11: Operating System Structure



            The job of the HAL is to present the rest of the operating system with abstract hardware devices,   Notes
            in  particular,  devoid  of  the  warts  and  idiosyncracies  with  which  real  hardware  is  so  richly
            endowed. These devices are presented in the form of machine-independent services (procedure
            calls and macros) that the rest of the operating system and the drivers can use. By using the
            HAL services (which are identical on all Windows 2000 systems, no matter what the hardware
            is)  and  not  addressing  the  hardware  directly,  drivers  and  the  kernel  require  fewer  changes
            when being ported to new hardware. Porting the HAL  itself is straightforward because all
            the machine-dependent codes are concentrated in one place and the goals of the port are well
            defined, namely, implement all of the HAL services.

            The services chosen for inclusion in the HAL are those that relate to the chip set on the parentboard
            and which vary from machine to machine within reasonably predictable limits. In other words,
            it is designed to hide the differences between one vendor’s parentboard and another one’s, but
            not the differences between a Pentium and an Alpha. The HAL services include access to the
            device registers, bus-independent device addressing, interrupt handling and resetting, DMA
            transfers,  control  of  the  timers  and  real-time  clock,  low-level  spin  locks  and  multiprocessor
            synchronization, interfacing with the BIOS and its CMOS configuration memory. The HAL does
            not provide abstractions or services for specific I/O devices such as keyboards, mice, or disks
            or for the memory management unit.

            As an example of what the hardware abstraction layer does, consider the issue of memory-
            mapped I/O versus I/O ports. Some machines have one and some have the other. How should
            a driver be programmed: to use memory-mapped I/O or not? Rather than forcing a choice,
            which would make the driver not portable to a machine that did it the other way, the hardware
            abstraction layer offers three procedures for driver writers to use for reading the device registers
            and another three for writing them:
            uc = READ_PORT_UCHAR(port);         WRITE_PORT_UCHAR(port, uc);
            us = READ_PORT_USHORT(port);        WRITE_PORT_USHORT(port, us);

            ul = READ_PORT_ULONG(port);         WRITE_PORT_LONG(port, ul);
            These  procedures  read  and  write  unsigned  8-,  16-,  and  32-bit  integers,  respectively,  to  the
            specified port. It is up to the hardware abstraction layer to decide whether memory-mapped
            I/O is needed here. In this way, a driver can be moved without modification between machines
            that differ in the way the device registers are implemented.
            Drivers often need to access specific I/O devices for various purposes. At the hardware level, a
            device has one or more addresses on a certain bus. Since modern computers often have multiple
            buses (ISA, PCI, SCSI, USB, 1394, etc.), it can happen that two or more devices have the same bus
            address, so some way is needed to distinguish them. The HAL provides a service for identifying
            devices by mapping bus-relative device addresses onto system-wide logical addresses. In this
            way,  drivers  are  not  required  to  keep  track  of  which  device  is  on  which  bus.  These  logical
            addresses are analogous to the handles the operating system gives user programs to refer to
            files and other system resources. This mechanism also shields higher layers from properties of
            alternative bus structures and addressing conventions.
            Interrupts have a similar problem—they are also bus dependent. Here, too, the HAL provides
            services to name the interrupts in a system-wide way and also provides services to allow drivers
            to attach interrupt service routines to interrupts in a portable way, without having to know
            anything about which interrupt vector is for which bus. Interrupt request level management is
            also handled in the HAL.

            Another HAL service is setting up and managing DMA transfers in a device-independent way.
            Both the system—wide DMA engine and DMA engines on specific I/O cards can be handled.



                                             LOVELY PROFESSIONAL UNIVERSITY                                   329
   331   332   333   334   335   336   337   338   339   340   341