Easy Driver Development is an essential component of the Unison architecture.  Linux driver development is a huge time and effort trap for embedded developers.  Easy driver development makes Unison substantially more effective than embedded Linux minimizing total cost of ownership (TCO) and time to market.

Easy Driver Development results from the Aggregate Server Pattern used for the I/O model in Unison.  By allowing for dynamic selection of the server based on the I/O interface, the servers in the system are completely independent and each server has its own unique driver model.  The use of this unique aggregation, servers and a set of six primitives to access the servers ensures that easy device driver develpment is the norm.

Given Unison's mirroring of the Linux and Unix like APIs, often users expect that an existing Linux driver will suffice under Unison.  This is not the case for several reasons.

• Linux drivers are subject to GPL unless they are dynamcially installed.  Linux device drivers are generally not available for use with Unison as GPL would apply to the entire application.
• Linux drivers offer a similar structure to Unison drivers (both have open close read write and ioctl); however, Linux drivers are rarely designed for small systems.  Bloated code and unnecessary functionality generally make them less than ideal for tiny embedded systems where bytes are counted.

Linux driver use is somewhat incompatible with easy driver development in the Unison world but it is possible.

Unison includes many device drivers and because these drivers use the server I/O design pattern, they are very easy to understand.  You can easily modify them to include new features, generally using the ioctl options.  This supports the principle of easy driver development - start from something close that works.

If you really need to start from scratch to do a device driver, you need to pick a server I/O design pattern (either file I/O or socket I/O) and simply provide the code to support open close read write and ioctl or the corresponding socket calls.  Code to support  the interrupt handling is also required so the i_set_interrupt handler call will likely be used along with mr_sigpost to signal interrupt service requirements. 

You can also use semaphores or any other mechanism that you want to sync with the ISR - mr_sigpost is just an easy way to block for all events in one place using mr_receive.  In all you need to understand less than 10 primitives and six basic primitives will do the job.  Easy driver development is a cornerstone of Unison.