Question about Linux kernel driver concurrency and locking

D1ver · 03-07-2013, 08:58 AM

Hello,
I've got a project where I've created a 16-bit Addr, 16-bit data interface between an embedded Linux chip and an FPGA. This interface is simply using GPIO pins to bitbash the data between the two devices.

I've made a simple char driver to provide this interface to user programs by reading and writing to /dev/mybus, and this interface works. However I run into problems if more than one process tries to read/write at a time.

The driver code looks a little something like

Code:

read(){
  //obtain spinlock
  //set gpio bus to input
  //bitbash address
  // toggle rd pin
  // read the data
  // release spinlock
}

Now after some more reading it seems that on non SMP systems spinlocks compile into no-ops, which would explain why my interface cannot handle multiple readers/writes at the same time.

So my question is, how best to provide a simple critical section inside the driver when more than one userspace program is accessing the read/write interfaces. It seems that semaphores are restricted to user space in Linux, are there any other options?

I'd prefer to have the driver handle the arbitration rather than trying to ensure that only one userspace program is accessing the driver at any one time.

Thanks,

sundialsvcs · 03-07-2013, 09:39 AM

Correct. Spinlocks are not required on SMP systems therefore they are not required. However, your driver must act as though they do, to arbitrate access to the hardware itself (the latches and so-forth that actually make the device operate).

In addition to this, however, you must implement software-level concurrency controls .. which have nothing at all to do with spinlocks. These are concerned with putting processes and threads to sleep and waking them up.

Your first question should be: what do you want to happen if more than one process/thread tries to use this device at the same time? Should they be allowed to open it? If so, and if more than one thread (natcherly ...) tries to read and write to it, what makes sense? What should the other computer on the other end of the wire expect to see? Or, if they're just blinking lights, how does it make sense for them to blink?

Once you know that, and making heavy use of existing driver source-code as your example, you'll build appropriate code into your driver to synchronize the activities of multiple processes without, of course, preventing them from being SIGKILLed. Again, just find an existing driver that already implements the intended behavior, and

read it.