Several processes accessing /dev/xillybus_xxx

Questions and discussions about the Xillybus IP core and drivers

Several processes accessing /dev/xillybus_xxx

Postby JohnT » Thu Jul 27, 2017 7:10 pm

Hi,

I have a several processes trying to access (rw) /dev/xillybus_xxx synchronously. If the device is already opened, the other process failed to open the device. Is there a way that the xillybus can support several processes accessing the device at the same time?.

Regards,

John
JohnT
 
Posts: 4
Joined: Thu Apr 13, 2017 9:24 pm

Re: Several processes accessing /dev/xillybus_xxx

Postby support » Thu Jul 27, 2017 8:03 pm

Hello,

Xillybus' driver was designed to be reentrant, so functionally, it supports having a device file opened by several processes (or threads).

However the driver indeed prevents opening a device file that is already opened, as this is a result of a mistake in most scenarios.

There are several ways to enable what you ask for -- the question is why you want to do it. What's the usage scenario that requires this? With the answer to that question in hand, I'll hopefully be able to suggest an elegant solution.

Regards,
Eli
support
 
Posts: 482
Joined: Tue Apr 24, 2012 3:46 pm

Re: Several processes accessing /dev/xillybus_xxx

Postby JohnT » Fri Jul 28, 2017 10:49 pm

Hi Eli,

We have a /dev/xillibus_xxx node to r/w the memory map of the FPGA. As an example, let say address 0x0 is status address, 0x2 control register, 0x4 temp address, 0x6 is ADC and 0x8 is DAC.

We have an application(A) to monitor the temperature and if the temperature changed, it needs to write a new DAC value, the application is running as a daemon.
The other application(B) is controlling the control register, check the status address.

The way we do it right now is:

while(1):
A->open (/dev/xillibus_xxx), (if failed, try to open it again),
read(temp)
write(dac)
close(/dev/xillibus_xxx).

B->open (/dev/xillibus_xxx), (if failed, try to open it again),
read(status)
write(ctlr)
close(/dev/xillibus_xxx).
exit

Regards,

John
JohnT
 
Posts: 4
Joined: Thu Apr 13, 2017 9:24 pm

Re: Several processes accessing /dev/xillybus_xxx

Postby JohnT » Sat Jul 29, 2017 12:14 am

Hi Eli,

We have a /dev/xillibus_xxx node to r/w the memory map of the FPGA. As an example, let say address 0x0 is status address, 0x2 control register, 0x4 temp address, 0x6 is ADC and 0x8 is DAC.

We have an application(A - Running as a daemon) to monitor the temperature and if the temperature changed, it needs to write a new DAC value.
The other application(B - command line program) is controlling the control register, check the status address.

The way we do it right now is:

while(1):
A->open (/dev/xillibus_xxx), (if failed, try to open it again),
read(temp)
write(dac)
close(/dev/xillibus_xxx).

B->open (/dev/xillibus_xxx), (if failed, try to open it again),
read(status)
write(ctlr)
close(/dev/xillibus_xxx).
exit

Regards,

John
JohnT
 
Posts: 4
Joined: Thu Apr 13, 2017 9:24 pm

Re: Several processes accessing /dev/xillybus_xxx

Postby support » Sat Jul 29, 2017 6:54 am

Hello,

Your example demonstrates why opening the device file was designed to be exclusive.

Suppose it wasn't, and process A and B would both open the device file. As you surely know, accessing the registers involves two stages: seeking and then reading or writing. Should both processes attempt to access the hardware at the same time, they could both issue seek commands more or less simultaneously, so when they reached the stage of read/write, at least one of them would access the wrong address in the memory map. This would probably become a rare bug in your case, which makes it even worse.

So opening and closing the device file each time isn't a bad idea, if the access isn't intensive (temperature reading, for example, is usually done at a low sample rate). You may want to use flock() on the device file (or any other dedicated file) for preventing the failure of opening the device file. This way, the waiting process will block, rather than looping on trying to open the file. It's a bit more elegant.

The point is that no matter what way you go, if you want more than one process to access the device file, you need a mutex to ensure that they never access it at the same time. For example, a multithreaded program with a POSIX mutex. You may start with a single process that opens the device file, and then forks into two daemons.

And lastly, you may modify the driver to allow nonexclusive opening of the device file. If you read the xillybus_open function, you'll see that it depends on the wr_exclusive_open and rd_exclusive_open flags.

So you may change, in xilly_setupchannels():

Code: Select all
exclusive_open = (chandesc[2] >> 7) & 0x01;


to
Code: Select all
exclusive_open = 0;

But this is probably not a good idea, for the reasons mentioned above.

No matter how you twist and turn this, you'll need a locking mechanism. And a software lock is a matter of programming discipline: When used with care, they work great. In a hacky environment, hell breaks loose.

Another possibility to consider is to have separate device files for each process, in particular if they're dealing with separate functionalities.
support
 
Posts: 482
Joined: Tue Apr 24, 2012 3:46 pm


Return to Xillybus

cron