[Xenomai-help] rt_dev_ioctl serialization

[Xenomai-help] rt_dev_ioctl serialization

[Paul Ianna]

Greetings,

Background:

I have not (yet) studied or written a linux or rtdm device driver.  I
am, however, using one whose source with which I am unfamiliar.  My
particular scenario involves a communications device driver written to
by many asynchronous tasks with varying priorities.  I am concerned
that I may need to provide protections in front of the rt_dev_ioctl
call to ensure coherency.


Question:

Does a call to rt_dev_ioctl implicitly handle serialization or is it
each driver's  (or application's) responsibility to take care of
serialization/reentrancy issues?


Thanks in advance,
Paul

Re: [Xenomai-help] rt_dev_ioctl serialization

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

Paul Ianna wrote:
> Greetings,
> 
> Background:
> 
> I have not (yet) studied or written a linux or rtdm device driver.  I
> am, however, using one whose source with which I am unfamiliar.  My
> particular scenario involves a communications device driver written to
> by many asynchronous tasks with varying priorities.  I am concerned
> that I may need to provide protections in front of the rt_dev_ioctl
> call to ensure coherency.
> 
> 
> Question:
> 
> Does a call to rt_dev_ioctl implicitly handle serialization or is it
> each driver's  (or application's) responsibility to take care of
> serialization/reentrancy issues?

It's first of all the driver's responsibility. There are so many
different usages even of basic services (read/write/recv/send) that a
common solution makes no sense. Depending on the usage model of the
driver, the degree of protection against concurrency may vary.

An example for this are the read and write handlers of xeno_16550A:
Writing concurrently is considered a potential valid scenario (though
rare), thus it is ensured via a blocking mutex that a data chunk can be
written atomically. In contrast, reading is not considered to happen
concurrently, and the applied protection against wrong usage is a simple
flag set on entry and reset on exit of the read handler. If a concurrent
read occurs, this will be rejected and the user will be warned via an
error code. The same protection is applied on RTSER_RTIOC_WAIT_EVENT.

That said, your particular driver (which one?) may behave differently.
Either this is documented somewhere, our you actually have to study the
sources to understand its characteristics.

HTH,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]