[Xenomai-core] Context-sharing semaphores

[Xenomai-core] Context-sharing semaphores

[Remco den Breeje]

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.

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

Thanks,

Remco den Breeje

Re: [Xenomai-core] Context-sharing semaphores

[Jan Kiszka]

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

Re: [Xenomai-core] Context-sharing semaphores

[Gilles Chanteperdrix]

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.
> 
> 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

This is supposed to work. Please post the full user-space and
kernel-space code so that we can investigate.

-- 
                                          Gilles

Re: [Xenomai-core] Context-sharing semaphores

[Remco den Breeje]

On Mon, Nov 9, 2009 at 2:06 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> The design. :)

I totally agree :) However, I'm using generated (user-space) code that
I want to modify as little as possible. So with a simple ioctl-call I
want to be able to switch between software (pthread) and hardware
triggering (rtdm-driver).

> 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

The sem_open documentation states  "a connection between the semaphore
named name and the calling context (kernel-space as a whole, or
user-space process)". I interpreted this as exactly what I want - a
synchronization between user- and kernel-space. Please correct me if
I'm wrong.

>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
>

Attached you find an example.
You can run it by executing: `make && sudo insmod ./km.ko && sudo ./um
; sudo rmmod km`

My syslog-output is: "Error opening clock semaphore (2)"

Thanks,

Remco den Breeje

Re: [Xenomai-core] Context-sharing semaphores

[Remco den Breeje]

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

Classic.

On Mon, Nov 9, 2009 at 3:22 PM, Remco den Breeje <remco@domain.hid> wrote:
> On Mon, Nov 9, 2009 at 2:06 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> The design. :)
>
> I totally agree :) However, I'm using generated (user-space) code that
> I want to modify as little as possible. So with a simple ioctl-call I
> want to be able to switch between software (pthread) and hardware
> triggering (rtdm-driver).
>
>> 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
>
> The sem_open documentation states  "a connection between the semaphore
> named name and the calling context (kernel-space as a whole, or
> user-space process)". I interpreted this as exactly what I want - a
> synchronization between user- and kernel-space. Please correct me if
> I'm wrong.
>
>>
>> --
>> Siemens AG, Corporate Technology, CT SE 2
>> Corporate Competence Center Embedded Linux
>>
>
> Attached you find an example.
> You can run it by executing: `make && sudo insmod ./km.ko && sudo ./um
> ; sudo rmmod km`
>
> My syslog-output is: "Error opening clock semaphore (2)"
>
> Thanks,
>
> Remco den Breeje
>

[-- Attachment #2: sem-sharing.tar.gz --]
[-- Type: application/x-gzip, Size: 3008 bytes --]

Re: [Xenomai-core] Context-sharing semaphores

[Gilles Chanteperdrix]

Remco den Breeje wrote:
> Attached you find an example.

No. There is nothing attached.
-- 
                                          Gilles

Re: [Xenomai-core] Context-sharing semaphores

[Gilles Chanteperdrix]

Remco den Breeje wrote:
> Classic.

Ok. I see nothing wrong, I will have a look at this tonight.

-- 
                                          Gilles

Re: [Xenomai-core] Context-sharing semaphores

[Gilles Chanteperdrix]

Remco den Breeje wrote:
> Classic.

Ah. Sorry. Found the bug in the mean time. It is in the Makefile. You do
not pass the compilation flags for compilation for Xenomai posix skin.
So, your user space application uses plain linux semaphores.

See:
doc/txt/pse51-skin.txt in xenomai sources
or:
http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags.

-- 
                                          Gilles

Re: [Xenomai-core] Context-sharing semaphores

[Remco den Breeje]

On Mon, Nov 9, 2009 at 3:49 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>
> Ah. Sorry. Found the bug in the mean time. It is in the Makefile. You do
> not pass the compilation flags for compilation for Xenomai posix skin.
> So, your user space application uses plain linux semaphores.

Ah, that makes sense.
I'm able to run my test-app after adding the posix flags.

Thanks a lot!

Remco

>
> See:
> doc/txt/pse51-skin.txt in xenomai sources
> or:
> http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags.
>
> --
>                                          Gilles
>
>

Re: [Xenomai-core] Context-sharing semaphores

[Gilles Chanteperdrix]

Remco den Breeje wrote:
> On Mon, Nov 9, 2009 at 3:49 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Ah. Sorry. Found the bug in the mean time. It is in the Makefile. You do
>> not pass the compilation flags for compilation for Xenomai posix skin.
>> So, your user space application uses plain linux semaphores.
> 
> Ah, that makes sense.
> I'm able to run my test-app after adding the posix flags.

Ok, thanks. But as Jan said, the future-proof design is to use an RTDM
driver. And for emulation purposes, you can create a dummy driver which
triggers an RTDM event unblocking the ioctl periodically.

-- 
                                          Gilles