[Xenomai-help] Sharing Semaphores in Kernel and User Space

[Xenomai-help] Sharing Semaphores in Kernel and User Space

[Jonathan Haws]

All,

I am writing a driver that needs to wake up a user space thread on a hardware interrupt.  I am reading about the Xenomai APIs semaphores and want to know if I create a semaphore in my kernel module with a given name using rt_sem_create, can I call rt_sem_bind in user space to bind to that same semaphore?

I am sure hoping the answer is yes!

Thanks,

Jonathan

Re: [Xenomai-help] Sharing Semaphores in Kernel and User Space

[Gilles Chanteperdrix]

Jonathan Haws wrote:
> All,
> 
> I am writing a driver that needs to wake up a user space thread on a
> hardware interrupt.  I am reading about the Xenomai APIs semaphores
> and want to know if I create a semaphore in my kernel module with a
> given name using rt_sem_create, can I call rt_sem_bind in user space
> to bind to that same semaphore?
> 
> I am sure hoping the answer is yes!

The answer is yes, but...
this programming model is deprecated. You should be implementing a
driver using the RTDM API, as you would do with Linux.

-- 
					    Gilles.

Re: [Xenomai-help] Sharing Semaphores in Kernel and User Space

[Jonathan Haws]

> > I am writing a driver that needs to wake up a user space thread on
> a
> > hardware interrupt.  I am reading about the Xenomai APIs
> semaphores
> > and want to know if I create a semaphore in my kernel module with
> a
> > given name using rt_sem_create, can I call rt_sem_bind in user
> space
> > to bind to that same semaphore?
> >
> > I am sure hoping the answer is yes!
> 
> The answer is yes, but...
> this programming model is deprecated. You should be implementing a
> driver using the RTDM API, as you would do with Linux.

The driver is a really dumb driver - all it really does is setup pointers to the PCI BARs and installs the interrupt.  I provide an mmap routine to map the BARs to user space so I can control the device from there.

Would this still be necessary to use the RTDM API?  I guess to install the interrupt, but there really is not anything else the driver does.

I was also reading the RTDM API and am confused about the rtdm_iomap_to_user() function - is that to be called from my user space application and it will then call the mmap routine that I have in place for my driver?

Re: [Xenomai-help] Sharing Semaphores in Kernel and User Space

[Jan Kiszka]

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

Jonathan Haws wrote:
>>> I am writing a driver that needs to wake up a user space thread on
>> a
>>> hardware interrupt.  I am reading about the Xenomai APIs
>> semaphores
>>> and want to know if I create a semaphore in my kernel module with
>> a
>>> given name using rt_sem_create, can I call rt_sem_bind in user
>> space
>>> to bind to that same semaphore?
>>>
>>> I am sure hoping the answer is yes!
>> The answer is yes, but...
>> this programming model is deprecated. You should be implementing a
>> driver using the RTDM API, as you would do with Linux.
> 
> The driver is a really dumb driver - all it really does is setup pointers to the PCI BARs and installs the interrupt.  I provide an mmap routine to map the BARs to user space so I can control the device from there.
> 
> Would this still be necessary to use the RTDM API?  I guess to install the interrupt, but there really is not anything else the driver does.

Abstraction is the primary job of a driver. Pushing things to user space
quickly blurs the boundaries and ends up in tricky to maintain blob on
the long term.

> 
> I was also reading the RTDM API and am confused about the rtdm_iomap_to_user() function - is that to be called from my user space application and it will then call the mmap routine that I have in place for my driver?

It's part of the function set that a driver can use, not an application.
This function will do all the work required to let some I/O memory show
up in the user space's memory range.

Jan


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

Re: [Xenomai-help] Sharing Semaphores in Kernel and User Space

[Jonathan Haws]

> >>> I am writing a driver that needs to wake up a user space thread
> on
> >> a
> >>> hardware interrupt.  I am reading about the Xenomai APIs
> >> semaphores
> >>> and want to know if I create a semaphore in my kernel module
> with
> >> a
> >>> given name using rt_sem_create, can I call rt_sem_bind in user
> >> space
> >>> to bind to that same semaphore?
> >>>
> >>> I am sure hoping the answer is yes!
> >> The answer is yes, but...
> >> this programming model is deprecated. You should be implementing
> a
> >> driver using the RTDM API, as you would do with Linux.
> >
> > The driver is a really dumb driver - all it really does is setup
> pointers to the PCI BARs and installs the interrupt.  I provide an
> mmap routine to map the BARs to user space so I can control the
> device from there.
> >
> > Would this still be necessary to use the RTDM API?  I guess to
> install the interrupt, but there really is not anything else the
> driver does.
> 
> Abstraction is the primary job of a driver. Pushing things to user
> space
> quickly blurs the boundaries and ends up in tricky to maintain blob
> on
> the long term.

That is what I am trying to do, abstract away the details of interfacing with the hardware, however the user does need to have access to the BARs to be able to configure the device at runtime in an efficient manner.  IOCTL calls are too slow for our application.  We do not need this driver to be very portable either - this is custom built hardware specific to our application only.

> > I was also reading the RTDM API and am confused about the
> rtdm_iomap_to_user() function - is that to be called from my user
> space application and it will then call the mmap routine that I have
> in place for my driver?
> 
> It's part of the function set that a driver can use, not an
> application.
> This function will do all the work required to let some I/O memory
> show
> up in the user space's memory range.

So, how would it be used?  Does the driver call this routine with some specific memory in mind and it returns a user space pointer?  If so, how does that pointer get passed back to user space?

I think for our application the RTDM driver is not necessary.  Simply synchronizing with a RT_SEM will do the trick for us.

Thanks for all the help!

Jonathan

Re: [Xenomai-help] Sharing Semaphores in Kernel and User Space

[Gilles Chanteperdrix]

Jonathan Haws wrote:
> I think for our application the RTDM driver is not necessary.  Simply
> synchronizing with a RT_SEM will do the trick for us.
> 
> Thanks for all the help!

Well, since you are at it, you can also use interrupts directly from
user-space with rt_intr* services.


-- 
                                          Gilles

Re: [Xenomai-help] Sharing Semaphores in Kernel and User Space

[Jan Kiszka]

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

Jonathan Haws wrote:
>>>>> I am writing a driver that needs to wake up a user space thread
>> on
>>>> a
>>>>> hardware interrupt.  I am reading about the Xenomai APIs
>>>> semaphores
>>>>> and want to know if I create a semaphore in my kernel module
>> with
>>>> a
>>>>> given name using rt_sem_create, can I call rt_sem_bind in user
>>>> space
>>>>> to bind to that same semaphore?
>>>>>
>>>>> I am sure hoping the answer is yes!
>>>> The answer is yes, but...
>>>> this programming model is deprecated. You should be implementing
>> a
>>>> driver using the RTDM API, as you would do with Linux.
>>> The driver is a really dumb driver - all it really does is setup
>> pointers to the PCI BARs and installs the interrupt.  I provide an
>> mmap routine to map the BARs to user space so I can control the
>> device from there.
>>> Would this still be necessary to use the RTDM API?  I guess to
>> install the interrupt, but there really is not anything else the
>> driver does.
>>
>> Abstraction is the primary job of a driver. Pushing things to user
>> space
>> quickly blurs the boundaries and ends up in tricky to maintain blob
>> on
>> the long term.
> 
> That is what I am trying to do, abstract away the details of interfacing with the hardware, however the user does need to have access to the BARs to be able to configure the device at runtime in an efficient manner.  IOCTL calls are too slow for our application.  We do not need this driver to be very portable either - this is custom built hardware specific to our application only.

No one says that every transfered byte need to be encapsulated into an
IOCTL. There can be clever device models that only issue driver calls
when the caller needs to wait on an event. Of course, this also depends
on the hardware's capabilities.

> 
>>> I was also reading the RTDM API and am confused about the
>> rtdm_iomap_to_user() function - is that to be called from my user
>> space application and it will then call the mmap routine that I have
>> in place for my driver?
>>
>> It's part of the function set that a driver can use, not an
>> application.
>> This function will do all the work required to let some I/O memory
>> show
>> up in the user space's memory range.
> 
> So, how would it be used?  Does the driver call this routine with some specific memory in mind and it returns a user space pointer?  If so, how does that pointer get passed back to user space?

It's typically in a driver's IOCTL handler that processes a user request
to set up the memory mapping for a specific device. So you pass the
pointer back and forth as an argument to this IOCTL. For details on the
service just look at its doc:

http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__util.html#gd3cd99bd0049763a4bf4c41edb249785

Jan


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