Re: Newbie: advice on general driver design

"[rob desbois]" <rob.desbois@xxxxxxxxx> writes:

[...]

There are several other board-specific devices controlled/read through
the PIO pins including front-panel LEDs, push buttons, and a dry
relay.
What is the 'best' way to (or how would you) design a driver for this?

[...]

The other functions do not involve transfer of data, but are more like
command-type functions. I will implement a set of ioctl() commands (or
look at sysfs for this) to do the following:
SET_LED const u32* led /* turn on LED */
CLEAR_LED const u32* led /* turn off LED */

SET_RELAY const u8* nc /* set relay to (nc? normally-closed :
normally-open) */

GET_BUTTON const u32* button, u8* down /* down = true if button is
down */

Any comments on this design?

Depending on how you want to use this, having different ioctls
operating on the same device node may be a bad choice. Eg, this makes
it complicated to use the PIOs from shell scripts. Some people
apparently have a 'philosophical distaste' for using the shell, but I
would never code anything in C when writing a shell script instead
would be sufficient. Consequently, I have a GPIO driver (for Linux
2.4), which registers different character devices for each pin (using
a single major number) and modify them by writing to the corresponding
device node, eg the

printf 0 >/dev/led

shell command can be used to turn the LED on, and

printf 1 >/dev/led

turns it off again. With ioctls, a special-purpose tool would be
necessary to do the same from a script (or even multiple
special-purpose tools).

A nice UNIX(*)-design tradition is to write primitives in C insofar
this is required for interfacing with some part of the system or
because a particular task needs to be fast[*] and glue these together
using shell scripts. I found this to be a very usable way to
accomplish complex tasks in a 'limited' environment [**].

[*] Eg I have a 'form-header' tool which just prints
'Content-Type: text/html\r\n\r\n' to stdout. Believe it or
not, but this improves the latencies of interactive web pages
implemented by shell scripts noticeably.

[**] The only interpreter on my 'device platform' is the
busybox-ash.
.

Quantcast