Mouse Drivers | ||
---|---|---|
Prev |
This leaves the missing feature - Asynchronous I/O. Normally UNIX
programs use the poll
call (or its variant form
select
) to wait for an event to occur on one of
multiple input or output devices. This model works well for most tasks
but because poll
and select
wait for an event isn't suitable for tasks that are also continually
doing computation work. Such programs really want the kernel to kick
them when something happens rather than watch for events.
Poll is akin to having a row of lights in front of you. You can see at a glance which ones if any are lit. You cannot however get anything useful done while watching them. Asynchronous I/O uses signals which work more like a door bell. Instead of you watching, it tells you that something is up.
Asynchronous I/O sends the signal SIGIO to a user process when the I/O events occur. In this case that means when people move the mouse. The SIGIO signal causes the user process to jump to its signal handler and execute code in that handler before returning to whatever was going on previously. It is the application equivalent of an interrupt handler.
Most of the code needed for this operation is common to all its users. The kernel provides a simple set of functions for managing asynchronous I/O.
Our first job is to allow users to set asynchronous I/O on file handles. To do that we need to add a new function to the file operations table for our mouse:
struct file_operations our_mouse_fops = { owner: THIS_MODULE read: read_mouse, /* You can read a mouse */ write: write_mouse, /* This won't do a lot */ poll: poll_mouse, /* Poll */ open: open_mouse, /* Called on open */ release: close_mouse, /* Called on close */ fasync: fasync_mouse, /* Asynchronous I/O */ };
Once we have installed this entry the kernel knows we support
asynchronous I/O and will allow all the relevant operations on the
device. Whenever a user adds or removes asynchronous I/O notification
on a file handle it calls our fasync_mouse
routine
we just added. This routine uses the helper functions to keep the queue
of handles up to date:
static struct fasync_struct *mouse_fasync = NULL; static int fasync_mouse(int fd, struct file *filp, int on) { int retval = fasync_helper(fd, filp, on, &mouse_fasync); if (retval < 0) return retval; return 0; }
The fasync helper adds and deletes entries by managing the supplied list. We also need to remove entries from this list when the file is closed. This requires we add one line to our close function:
static int close_mouse(struct inode *inode, struct file *file) { fasync_mouse(-1, file, 0) if(--mouse_users) return 0; free_irq(OURMOUSE_IRQ, NULL); MOD_DEC_USE_COUNT; return 0; }
When we close the file we now call our own fasync handler as if the user had requested that this file cease to be used for asynchronous I/O. This rather neatly cleans up any loose ends. We certainly don't wait to deliver a signal for a file that no longer exists.
At this point the mouse driver supports all the asynchronous I/O operations, and applications using them will not error. They won't however work yet. We need to actually send the signals. Again the kernel provides a function for handling this.
We update our interrupt handler a little:
static void ourmouse_interrupt(int irq, void *dev_id, struct pt_regs *regs) { char delta_x; char delta_y; unsigned char new_buttons; delta_x = inb(OURMOUSE_BASE); delta_y = inb(OURMOUSE_BASE+1); new_buttons = inb(OURMOUSE_BASE+2); if(delta_x || delta_y || new_buttons != mouse_buttons) { /* Something happened */ spin_lock(&mouse_lock); mouse_event = 1; mouse_dx += delta_x; mouse_dy += delta_y; if(mouse_dx < -4096) mouse_dx = -4096; if(mouse_dx > 4096) mouse_dx = 4096; if(mouse_dy < -4096) mouse_dy = -4096; if(mouse_dy > 4096) mouse_dy = 4096; mouse_buttons = new_buttons; spin_unlock(&mouse_lock); /* Now we do asynchronous I/O */ kill_fasync(&mouse_fasync, SIGIO); wake_up_interruptible(&mouse_wait); } }
The new code simply calls the kill_fasync
routine
provided by the kernel if the queue is non-empty. This sends the
required signal (SIGIO in this case) to the process each file handle
says should be informed about the exciting new mouse movement that
just happened.
With this in place and the bugs in the original version fixed, you now have a fully functional mouse driver using the bus mouse protocol. It will work with the X window system, will work with GPM and should work with every other application you need. Doom is of course the ideal way to test your new mouse driver is functioning properly. Be sure to test it thoroughly.