06-07-2012, 11:26 AM
I/O Multiplexing
input output multiplexing.ppt (Size: 64.5 KB / Downloads: 86)
Remember ‘read()’ semantics
If device-driver’s ‘read()’ function is called before the device has any data available, then the calling task is expected to ‘sleep’ on a wait-queue until the device has at least one byte of data ready to return.
The keyboard’s device-driver behaves in exactly that expected way: it ‘blocks’ if we try to read when there are no keystrokes.
Blocking versus Multiplexing
If we want to read from multiple devices, we are not able to do it properly with the read() system-call
If one device has no data, our task will be blocked, and so can’t read data that may become available from some other device
Better idea: use ‘select()’
The ‘select()’ system-call was designed to allow applications to efficiently perform i/o multiplexing
With ‘select()’ the application informs the kernel as to which system devices it is interested in
The kernel then ‘polls’ those devices, to see if any of them is ready to do i/o without blocking
If not, it puts the process to sleep until at least one device is ready to do i/o without blocking
Driver needs ‘poll()’ method
To support the ‘select()’ system-call, our ‘tsc.c’ driver needs to implement ‘poll()’
Our textbook tells what we need to do
Just two things:
Need to call the kernel ‘poll_wait()’ function
Return a bitmap indicating device readiness
An experiment with ‘poll()’
Modify the ‘tsc.c’ device-driver code
Include ‘poll()’ in ‘file_operations’ struct
Use a kernel software timer in ‘read()’
Use 5-second delay between ‘reads’
Run ‘watchtsc’ with polling implemented
And run ‘watchtsc’ with polling ommitted
Note responsiveness to keyboard input!