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 driver converts system calls such as open, read, write, close to low level comands to control device
Device conntroler convers command to electronic signals.
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.
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 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.
Suppose we want to read a sequence of charecters from a device
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)
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.
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
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.