From: Jan Kiszka <jan.kiszka@domain.hid>
To: Remco den Breeje <remco@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] Context-sharing semaphores
Date: Mon, 09 Nov 2009 14:06:26 +0100 [thread overview]
Message-ID: <4AF813D2.2000001@domain.hid> (raw)
In-Reply-To: <ddc6e05e0911090400r37e0160aha2c3088dc673c0aa@domain.hid>
Remco den Breeje wrote:
> Hi all,
>
> I'm having trouble trying to share a semaphore that is created in
> user-space context with a rtdm-driver that runs in kernel-space. I was
> hoping you could explain me what I'm doing wrong.
The design. :)
>
> I'm using a posix-skin based user-space Xenomai application that runs
> a loop which is triggered by a semaphore.
> This semaphore is posted by a pthread that runs at a specific
> frequency. However, I want to be able to synchronize this loop with an
> external hardware trigger that is read out by a rtdm-driver. To do so,
> I try to disable the semaphore-post in the user-mode pthread, and
> re-use the existing semaphore in kernel-mode (the rtdm-driver).
> Unfortunately, the rtdm-driver is not able to find the user-space
> created semaphore.
>
> I wrote a little test-program to explain the problem. If required, I
> will post the complete test-program, but for now I will show some
> code-snippets.
>
> In the user-space application a semphore is created using the sem_open sys-call:
>
> clockSem = sem_open(SEMNAME, O_CREAT, 0, 0);
>
> clockSem, which is a pointer to sem_t returns an address (!= SEM_FAILED).
> With an ioctl-call I try to open the same semaphore in kernel-mode:
>
> sem_p = sem_open(SEMNAME, 0);
>
> This fails. sem_p equals SEM_FAILED, and errno is set to 2 (ENOENT).
>
> I'm runing Linux 2.6.29.4 x86 32bit, Xenomai 2.4.8, ipipe 2.4-01
>
The proper design is to use a rtdm semaphore or event *inside* the
kernel and let the application block on it when it calls a related IOCTL
or other device function that shall synchronize on that condition.
Don't share resources like this between kernel and user space. It's
unclean, specifically as you once may want to access driver managed data
along the sleeping/waking as well.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2009-11-09 13:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-09 12:00 [Xenomai-core] Context-sharing semaphores Remco den Breeje
2009-11-09 13:06 ` Jan Kiszka [this message]
2009-11-09 14:22 ` Remco den Breeje
2009-11-09 14:23 ` Remco den Breeje
2009-11-09 14:46 ` Gilles Chanteperdrix
2009-11-09 14:49 ` Gilles Chanteperdrix
2009-11-09 15:20 ` Remco den Breeje
2009-11-09 15:41 ` Gilles Chanteperdrix
2009-11-09 14:25 ` Gilles Chanteperdrix
2009-11-09 13:19 ` Gilles Chanteperdrix
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=4AF813D2.2000001@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=remco@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.