An Operating Systems Vade Mecum

The process interface 177the channel program invalid or must introduce a hidden copying of data from a kernelbuffer. Device addresses must also be modified or at least checked for validity. Otherwisea process could blithely damage data on any sector of the disk. Usually the operatingsystem provides an environment for the process that includes ‘‘virtual tracks,’’ andreferences to these tracks must be mapped by the operating system to the actual tracksthat are supporting them. With luck, the size of a virtual track is the same as the size of aphysical track.5.3 Implementing the service callsIt is not hard for the envelope (the module of the kernel that first receives service calls) totranslate device service calls into requests on the upper parts of the appropriate devicedrivers. The context block for each process includes an array of open device descriptorrecords. The device descriptor given to the process can be an index into this array. Thedescriptor-record array might look as follows.1 OpenDevices : array 0:MaxOpenDevice of2 record { open device descriptor }3 InUse : Boolean; { false if this array entry is free }4 DeviceType : (Tape, Disk, File, Memory, Printer ... )5 DeviceNumber : integer; { which tape, etc. }6 CurrentPosition : integer; { which physical byte }7 Mode : (ReadOnly, ReadWrite, WriteOnly, AppendOnly);8 end { open device descriptor }A free slot is characterized by a false InUse field.When a process submits the Open call, a free descriptor record is found. TheInUse field is set to true, the DeviceType and DeviceNumber fields are initialized (basedon the details of the Open call), the CurrentPosition is set to zero, and the Mode field isset. The kernel then calls the ‘‘open’’ routine in the upper part of the appropriate devicedriver. The index of the open device descriptor is returned to the process so that furtheroperations it makes on this device can be associated with the current location andchecked against the Mode.When a process requests a Read, for example, to read 10 bytes from a disk, thedisk driver can calculate which sector in which track contains those bytes. A request forthat entire disk block is submitted to the lower part of the disk driver. When the blockhas been read in, the upper part transfers the desired 10 bytes to the address space of therequesting process and then either unblocks it (if synchronous transfer was specified) ortakes other appropriate action to inform the process that the transfer has completed. Ifthe request crosses block boundaries, several requests are then made of the lower part ofthe device driver.Writing bytes to a device may also require several successive calls to the lowerpart of the appropriate device driver. For example, to write less than a full block to adisk, the proper block or blocks must first be read in. Then their contents are modified inaccordance with the details of the Write call. They are then written back out. Writing toa magnetic tape is simpler because it is assumed that such a write will destroy the previouscontents. Writing to an otherwise unused disk block is also simpler because there isno need to preserve previous values.