In order to make some of the material we have now covered on device drivers a little more concrete we'll work through a simple example character device driver. The specification for the device driver we are going to develop may seem a bit artificial but it does allow you to see several interesting ideas put into practice.
The specification is as follows - Implement a character device driver which uses two device special files to allow a pair of processes to send short variable length text messages to each other. The driver should make sure that multiple readers and multiple writers are not permitted and also that read()s will not block even when there are no messages to read and that write()s will not block however many messages are written before the next read() occurs.
I should point out straight away that this last requirement, about unlimited write capacity, is dangerous as it is possible for some kind of error to stop the consumer process from reading any data. This leaves the producer process writing messages unchecked until, eventually, the system runs out of space to store them. In fact, for long lived processes there doesn't even need to be any kind of error for this problem to occur eventually. All that is required is that, on average, the producer is generating messages faster than the consumer can use them up. With this in mind, it might be sensible to set some arbitrary, but large, limit on the number of messages that can be stored simultaneously within the device driver. I leave this safety check as a coding exercise for you to add later.
In effect, this device driver is just going to control some system memory as its 'hardware device' and effectively provide an extra IPC mechanism in addition to those already available. The IPC semantics provided by this new driver, however, are quite different from those available with the existing IPC mechanisms.