Devices

3 minute read

Data can travel from devices using a bus.

Problem of using a bus could cause bus contention which means multiple devices all competing for the same bus. If one device is talking via the bus then all other devices have to wait.

Devices usually have their own set of registers (not CPU registers).

Register may have status reg - indicates busy or ready may have command / control registers data regs - to send / receive data

CPU may have dedicated I/O instructions to alter / inspect device registers.

A popular alternative is to map those registes onto memory locations so instead of using special instructions for input / output we simply access specific memory locations.

The low part of memory might be used to map onto our devices. Writing to location 100 might send a command to a device.

I/O devices can be categorised by their behaviors into generic classes.

the device driver hides these differences from the high level operating system. The device driver is a low level piece of code which acts as a translator to convert read and write calls to the actual commands that are sent to the device. Although we can group a device into a generic class they may still differ in properties.

Devices may vary on dimensions.

Device handling

device driver converts system calls such as open, read, write, close to low level comands to control device

  • it may have to be installed for a new device. You don’t know what new devices are goin to be come available and what the functional of these devices will be so the way to overcome this is to allow for a new device; the installation of a device driver for this device. You have to be very careful about the device driver you install.
  • A poorly written device driver can easily lead to an unstable system because of how close the driver is to the kernel. Or it can open up holes in security.

Device conntroler convers command to electronic signals.

Applcation interface

Unix /dev directory holds special files one per device. Accessing special file activates device driver System call ioctl() can be used to pass arbitrary commands to device driver.

terminal handling

Every charecter youtype enters intoa n input queue by device driver to echo, driver copies input queue to output queue becausee everything you write should appear on the screen. So it’s going off and coming back again.

Some of those charecters requrie further processing by device driver.

Some charecters requrie further processing by device driver

when read request made, pass contents of input queue to process.

The input queue can have an input queue limit but you can’t really hit the upper limit.

I/O scheduling

I/O requests need to be scheduled to execute in an efficient order. You want to deal with them in the most efficient way possible.

A good ordering can improve system performance, ensure devices are shared fairly amongst processes, reduce average I/O completion wait time.

We end up with a lot of wait queues of requests for each device. You could just deal with them in order but to improve efficieny what the system may do is reorder those requests. If it can work out a better ordering than it may move requests around just to improve overall efficieny.

Some processes may have higher priorities than others.

  • first come first served
  • shortest seek time first - the way your disk is structured means the read write heads are constantly moving across locations on the disk. What you may want to do is reduce the amount of head travel on the disk. We reshcedule items in the queue so we minimise travel time between blocks of information.

Buffering

Suppose we want to read a sequence of charecters from a device

  • making a read request for each char is costly. Instead, set up an area of memory called a buffer
  • read a block of chars into buffer in one operation
  • subseqeuent chars taken directly from buffer
  • only need to access device when buffer empties

double buffering

  • read nad write one buffer while other being filed / emptied

buffering may be done by

  • software (operating systems or library routinesl ike printf)
  • may also be done in hardware

At which of the following times should a Unix sync operation be performed?

when a process terminates when a process is created whenever a process outputs to a file loss of power system startup

The answer is loss of power, System is about to die, so dump all output to disk

direct memory access (Dma)

  • device such as disk drive instead of constantly interrupting the CPU it has direct memory access. May write directly into buffer.
  • cpu might be delayed while DMa cntrollerr accesses memory (cycle stealing)

buffer writes can cause inconsistancy problems. Unix calls a sync operation every 30 seconds so any data that is being in a buffer is flushed.

Buffers write data to disks.

caching

we have already looked at cache memory more generally, caching uses a faster medium to act in place of a slower one. so areas of main memory can be used to cache copies of items on disk

  • may also lead to incocsistency problems

spooling

some devices are not sharable

the solution is something called a spooler SPOOL stands for simultaenous perhiapal operations on-line each process sends it printer output not to a printer but to a daemon process which puts it all into a file.

it creates a temp file for each process and writes output to these files.

when the process completes the spooler adds the file to a queue for printing (de-spooling).

allows multiple processes to send different files to same device.