USF CS 686 - Input and Output multiplexing

Unformatted text preview:

i/o multiplexingAn application idea‘netchat.cpp’Multiplexed input-streamsDevice-driver’s roleThe basic problem‘read()’ causes ‘blocking’Do multiprocessing?Different processes do ‘read()’Non-blocking ‘read’Code-modificationUses ‘busy-waiting’ loopThe ‘elegant’ solutionThe ‘select()’ argumentsUsing ‘select()’ in ‘netchat’How it worksstruct file_operationsOur driver’s ‘poll()’ methodThe ‘ncurses’ libraryCompiling ‘netchat’Try it outBut…In-class exercisei/o multiplexingOn adding a ‘poll()’ method to our character-mode device-driver for an 82573L network controllerAn application idea•We want to create an application program that would allow two users to conduct an on-line chat-session while working from two separate nodes on our ‘anchor’ cluster•Whatever either user decides to type will be displayed on the both users’ screens•To keep their two input-streams visually separated we want to use two ‘windows’‘netchat.cpp’Hello, SusanHi, Paul_Hi, PaulHello, Susan_anchor01 anchor02 Whatever a user types will be displayed in the lower window on that user’s screen -- and in the upper window on the other user’s screenMultiplexed input-streams•In order to implement the foregoing idea, it’s necessary for the ‘netchat’ program to accept input from TWO hardware devices:–the keyboard (i.e., ‘standard input’ device)–the ethernet controller (i.e., ‘/dev/nic’) •Such a situation is a fairly common one in UNIX/Linux application programming, and is referred to as ‘i/o multiplexing’Device-driver’s role•Special software support is needed within each of the device-drivers in order for any application-program to do ‘i/o multiplexing’ in a way that avoids wasting of CPU time•(For an excellent discussion of the various approaches that can be taken to deal with this basic programming issue, see Richard Stevens: Advanced Programming in the UNIX Environment, Chapter 12)The basic problem•Normally when an application ‘reads’ from a device-file, that process will ‘sleep’ until some data is available from that device•So if data becomes available on another device, it will not get processed because the application is ‘blocked’ from being given any CPU time by the OS scheduler•This would spoil our ‘netchat’ application‘read()’ causes ‘blocking’ ‘netchat’ application terminalEthernetcontroller Whichever device the application attempts to read from, it will get ‘blocked’ until that device has some data to deliverreadreadwritewriteDo multiprocessing?•One idea for getting around this ‘blocking’ problem would be to just use the ‘fork()’ system-call to create a separate process for reading from the different device-files•Each process can sleep, and whichever process receives any new data will be awakened and scheduled for execution•No changes needed to device-driver codeDifferent processes do ‘read()’‘netchat’ parent- processterminalEthernetcontroller ‘netchat’ child-process readreadwritewrite Using multiple processes can overcome the ‘blocking-read’ problem, but complicates the code for program terminationNon-blocking ‘read’•It is possible for the application to request ‘non-blocking’ read-operations – i.e., any ‘read()’ calls will immediately return with 0 as return-value in case no data is available•The standard-input device-driver already has support for this non-blocking option, and it can be easily added to the ‘read()’ function in network controller’s driverCode-modificationssize_t my_read( struct file *file, char *buf, size_t len, loff_t *pos ){static int rxhead = 0;// in case no new data has been received, then either// return immediately if non-blocking mode is in effect// or else sleep until some new data arrives (or until // the user hits <CONTROL>-C to cancel execution) if ( rxhead == ioread32( io + E1000_RDH ) {if ( file->f_flags & O_NONBLOCK ) return 0;if ( wait_event_interruptible( wq_rx, rxring != ioread32( io + E1000_RDH ) )return –EINTR;}…Uses ‘busy-waiting’ loop ‘netchat’ application terminalEthernetcontrollerreadreadwrite Using the ‘nonblocking-read’ option overcomes the problem of a sleeping task, but it wastefully consumes the CPU timewriteThe ‘elegant’ solution•The ‘select()’ system-call provides a very general scheme for doing i/o-multiplexing in a manner that avoids wasting CPU time or making the program-code complicated•But it does require adding an extra driver ‘method’ – the so-called ‘poll()’ functionThe ‘select()’ arguments•Using ‘select()’ requires an application to setup an ‘fd_set’ object, which defines the set of file-descriptors whose activity needs to be monitored by the Linux kernel (in our ‘netchat’ application this would be just the two device-files: the console keyboard and the gigabit ethernet network controller) •This ‘fd_set’ object becomes an argumentUsing ‘select()’ in ‘netchat’ int kbd = STDIN_FILENO; // keyboard ID int aux = open( “/dev/nic”, O_RDWR ); // device-file IDfd_set permset; // create an ‘fd_set’ object FD_ZERO( &permset ); // initialize it to ‘empty’FD_SET( kbd, &permset ); // add keyboard to setFD_SET( aux, &permset ); // and add the nic to setwhile (1) {fd_set readset = permset;if ( select( 1+aux, &readset, NULL, NULL, NULL ) < 0 ) break;if ( FD_ISSET( kbd, &readset ) ) { /* process keyboard input */ }if ( FD_ISSET( aux, &readset ) ) { /* process network input */ }}How it works•The ‘readset’ argument to the ‘select()’ system-call lets the kernel know which device-drivers should have their ‘poll()’ method invoked•Then each device-driver’s ‘poll()’ method will perform a test to determine if any new data is ready to be read from that device•So the application calls ‘read()’ only when a device is ready with data immediatelystruct file_operations•We need to include the function-pointer to our implementation for the ‘poll()’ method: struct file_operations my_fops = {owner: THIS_MODULE,read: my_read,write: my_write,ioctl: my_ioctl,poll: my_poll,};Our driver’s ‘poll()’ method•Linux provides helper-functions to do most of the supporting work for use of ‘select()’ #include <linux/poll.h> // for the ‘poll_wait()’ helper-function unsigned int my_poll( struct file *file, struct poll_table_struct *wait ) {unsigned int


View Full Document

USF CS 686 - Input and Output multiplexing

Documents in this Course
Load more
Download Input and Output multiplexing
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Input and Output multiplexing and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Input and Output multiplexing 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?