All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Jonathan Haws <Jonathan.Haws@domain.hid>
Cc: "xenomai@xenomai.org" <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] Sharing Semaphores in Kernel and User Space
Date: Fri, 06 Nov 2009 09:33:21 +0100	[thread overview]
Message-ID: <4AF3DF51.70402@domain.hid> (raw)
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F03310309AA@midas.usurf.usu.edu>

[-- 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 --]

      parent reply	other threads:[~2009-11-06  8:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-04 23:19 [Xenomai-help] Sharing Semaphores in Kernel and User Space Jonathan Haws
2009-11-04 23:24 ` Gilles Chanteperdrix
2009-11-04 23:34   ` Jonathan Haws
2009-11-05  8:51     ` Jan Kiszka
2009-11-05 15:16       ` Jonathan Haws
2009-11-05 16:42         ` Gilles Chanteperdrix
2009-11-06  8:33         ` 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=4AF3DF51.70402@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=Jonathan.Haws@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.