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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
