I want to synchronize a user space thread to an external event that
generates an interrupt. I thought of using the following approach: the
ISR that treats the interrupt does a quick processing (such as data
capture and buffering) and then sends data to the user space thread
through a message queue or signals to the thread waiting on a
semaphore and it gets the buffered data from shared memory or some
similar mechanism. So far I haven't succeded in finding a way to do
it. I've tryed to write a module which uses semaphores (<linux/sem.h> )
but aparently there is no way to use SysV IPC primitives in kernel
modules.

I would appreciate having hints on how to do it or pointers to
documentation and example code if available.

Thank you very much in advance for your help.

Elder.

[ Post a follow-up to this message ]

Mad@Spammers wrote:
> I want to synchronize a user space thread to an external event that
> generates an interrupt. I thought of using the following approach: the
> ISR that treats the interrupt does a quick processing (such as data
> capture and buffering) and then sends data to the user space thread
> through a message queue or signals to the thread waiting on a
> semaphore and it gets the buffered data from shared memory or some
> similar mechanism. So far I haven't succeded in finding a way to do
> it. I've tryed to write a module which uses semaphores (<linux/sem.h> )
> but aparently there is no way to use SysV IPC primitives in kernel
> modules.
>
> I would appreciate having hints on how to do it or pointers to
> documentation and example code if available.
>
> Thank you very much in advance for your help.
>
> Elder.

A user-space signal is the equivalent of an interrupt.
When user-space drivers are involved, I like to use
"send_sig_info()" to send a signal to the user-space
task to indicate changes in the state of the driver.

I like to model the user/kernel space interface to
look like a hardware device in terms of interrupt/signal
handling, with ioctl's to acknowledge/enable/disable
signals/interrupts from the driver. However, I'm an
embedded type that is used to that kind of thing ;-)

Getting the data to/from kernel space is another
issue, typically done by the read/write driver
interface, or by using mmap().

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"... abstractions save us time working, but they don't
save us time learning."
Joel Spolsky, The Law of Leaky Abstractions

The Beatles were wrong: 1 & 1 & 1 is 1

[ Post a follow-up to this message ]

On 29 Apr 2004, Mad@Spammers wrote:

> I want to synchronize a user space thread to an external event that
> generates an interrupt.

Maybe the ongoing work about D-Bus can give you inspiration:
<http://freedesktop.org/Software/dbus>
One of its motivations was/is exactly to be able to do more driver stuff in
user space, and I got the impression that that was what you are looking
for...

Herman
--
K.U.Leuven, Mechanical Eng.,  Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480

[ Post a follow-up to this message ]

Michael N. Moran wrote: 
>
> A user-space signal is the equivalent of an interrupt.
> When user-space drivers are involved, I like to use
> "send_sig_info()" to send a signal to the user-space
> task to indicate changes in the state of the driver. ...
>
> Getting the data to/from kernel space is another
> issue, typically done by the read/write driver
> interface, or by using mmap().

What kind of time resolution do you need?

One other option is to use netlink sockets.  They're
pretty easy.  One drawback is netlink socket addresses
are somewhat precious, a little like signal numbers.

- Dan

[ Post a follow-up to this message ]

Hello Elder,

> I want to synchronize a user space thread to an external event that
> generates an interrupt. I thought of using the following approach: the
> ISR that treats the interrupt does a quick processing (such as data
> capture and buffering) and then sends data to the user space thread

- Let your driver register a character interface
- from your user space thread, do a synchronous read.
- in your interrupt routine, copy the data and wakeup the
waiting thread.

Very common situation. Works without any problem for me.

best regards

Wolfgang Mües

[ Post a follow-up to this message ]

Dan Kegel <dank-news@kegel.com> wrote in message

> What kind of time resolution do you need?
>
I presume this question was asked to me.

I am just evaluating how well would Linux (either 2.4 with preemption
and low latency patches or 2.6 with preemption enabled) perform for my
application. Worst case interrupt latency of 400us and thread
activation latency of 4ms are more than acceptable in my application.

Regards.

Elder.

[ Post a follow-up to this message ]

Herman Bruyninckx <Herman.Bruyninckx@mech.kuleuven.ac.be> wrote in message news:<Pine.LNX.4.
44.0404291542290.9591-100000@srv04.mech.kuleuven.ac.be>...
> On 29 Apr 2004, Mad@Spammers wrote:
> 
>
> Maybe the ongoing work about D-Bus can give you inspiration:
>   <http://freedesktop.org/Software/dbus>
> One of its motivations was/is exactly to be able to do more driver stuff i
n
> user space, and I got the impression that that was what you are looking
> for...
>
> Herman

I had a quick look at it. My requirements are much more modest and I'd
rather use native linux resources instead. Still I will look at its
code for some tips.

Elder.

[ Post a follow-up to this message ]

X-No-Archive:yes

A certain Mad@Spammers, of comp.arch.embedded "fame", writes :

>I would appreciate having hints on how to do it or pointers to
>documentation and example code if available.

What you'll need to do is create a device driver with an entry in /dev,
and then set up a poll()/select() call within it. These can be used to
inform a user space application that some data has arrived to be
processed.

Your user space code can open the device and use the above functions
which among other things provide the ability to block a thread until an
interrupt is received, etc. Much more elegant than signal processing.

The free book "Linux Device Drivers" covers this subject in detail.

--

"Jokes mentioning ducks were considered particularly funny." - cnn.com

[ Post a follow-up to this message ]

X-No-Archive:yes

A certain Mad@Spammers, of comp.arch.embedded "fame", writes :
 
>I presume this question was asked to me.
>
>I am just evaluating how well would Linux (either 2.4 with preemption
>and low latency patches or 2.6 with preemption enabled) perform for my
>application. Worst case interrupt latency of 400us and thread
>activation latency of 4ms are more than acceptable in my application.

Supposedly the low-latency patch can give worst-case latency of around
150us, but you'd need to check out how this fits on your architecture.

--

"Jokes mentioning ducks were considered particularly funny." - cnn.com

[ Post a follow-up to this message ]

"Mad@Spammers" schrieb:
>
> I want to synchronize a user space thread to an external event that
> generates an interrupt.

Look at rtc.c in the Kernel source. They provide a blocking read to the
application to have it wait for an event. Her some data is provided to
the application, too.

-Michael

[ Post a follow-up to this message ]