user space control for device driver

Hello,

I'm currently learning how device drivers are written for Linux (and have to write one shortly). From what i understand, the final control provided to user space for accessing the driver functions is via a device file and system calls.

Now i've seen that the drivers use a variety of interfaces for this file- viz /dev entries, procfs entries, sysfs entries and debugfs entries.Which would be the right choice for a GPIO driver? Assuming i have 32 GPIO ports which i want to access, making a /dev entry for each port does not seem a good idea.What interface type would be ideal?

The /dev file provides access to the driver -- anything written to it is processed by the driver, and (presumably) delivered to the device.

So if you can structure the driver to interpret the input correctly, then you can select ports that way and just use the one /dev file.

If I were writing a GPIO driver, I would allow the user to echo commands to the device node. For example, if the user wants to create some as INPUT some as OUTPUT I would allow the following string:

echo "C0x4821f103M0x7ff2f10f" > /dev/gpio

Which would mean: (C)onfigure the bits represented by (M)ask 0x7ff2f10f with the configuration of ON being input, OFF being output. Therefore, the driver would know to adjust the input/output mask of the GPIO pin IFF the mask value is set. -- Make sense?

Likewise a read would have a command:
echo "R0x0000000f" /dev/gpio
cat /dev/gpio
To indicate Read for me ONLY the last 4 bits of the GPIO and would return something like:
0x00000006
to the user.

This would GREATLY simplify your work (as you don't have to do any of the ioctl() subsystem calls) and it makes it so that you can access the GPIO from the command line -- which is often times VERY helpful.

0.02 USD.

Kennedy makes a good point about ease of implementation and use, but it's not a very traditional way to go about it. Usually, device commands are implemented by ioctl() calls, and reads/writes to the device are used to transfer raw data after the device has been configured in some way.

Specially formatted string input/output is the kind of thing you usually find in /proc nodes.

I realize that implementing ioctl()'s can be painful and boring, but it's the usual way.

Quote:

---

Originally Posted by brewbuck

I realize that implementing ioctl()'s can be painful and boring, but it's the usual way.

---

Please tell me that is not a justification...

I guess I would have to argue that point, as for GPIO there is normally no "usual" driver at all (1). Most of the controls I've seen for GPIO are in the form of highly complicated user-space apps that directly access memory via mem-mapping /dev/mem.

Nothing says that one cannot make the driver answer the call for ioctl(), but how many folks would ****WANT**** to have to access the GPIO from ioctl()?

Many of the GPIO lines I've used have been for controlling the LEDs provided with the board -- and that's about all. For any of the other functions that GPIO controls, one probably won't be looking at controlling individual lines, but alternate functions of the processor.

(1) this is certainly true for the Gumstix I've used and the 20-30 boards I've used from about 6-8 different companies (of which I can only recall the name of a couple, which were merged into one: Eurotech). Not a WIDE variety, but not a few either.