From: Jan Kiszka <jan.kiszka@domain.hid>
To: Paul Ianna <paulianna2002@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] rt_dev_ioctl serialization
Date: Tue, 29 Aug 2006 16:53:43 +0200 [thread overview]
Message-ID: <44F454F7.6010707@domain.hid> (raw)
In-Reply-To: <75975c320608290736r52e642fcrc2e9c5edb1551d03@domain.hid>
[-- 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 --]
prev parent reply other threads:[~2006-08-29 14:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-29 14:36 [Xenomai-help] rt_dev_ioctl serialization Paul Ianna
2006-08-29 14:53 ` Jan Kiszka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44F454F7.6010707@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=paulianna2002@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.