Synchronizing user space threads with kernel space in linux

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

Maybe the ongoing work about D-Bus can give you inspiration: 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
     Tel: +32 16 322480

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

Hello Elder,

- 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

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.

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.

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

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

"Mad@Spammers" schrieb:

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

Nope. Linux can't guarantee any worst-case latency at all (I did find more than 100 msek with the low-latency patch in very rare instances).

-Michael

That's why I was quite careful not to use the word "guarantee".

Clearly if you need hard real time performance, you need to look at another OS.

--

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

"Hard real-time means no surprises or silent failures as system configuration changes or load increases. Deadlines will still be met. For example, the worst case delay on a 1 millisecond thread on the HP Pavilion Notebook (AMD K7) is 12 microseconds. -

"RTAI's microkernel approach guarantees that the data-acquisition task will take place on schedule, even while the previously acquired and calculated result is written to disk." -

"Lineo Solutions, Inc. (Lineo) demonstrated ... hard real-time support with Linux .... Deterministic time metrics of the systems demonstrated ... is as follows.

Interrupt Response Time 5 microseconds

Task Latency Time 4 microseconds

Periodic Task Latency Time 20 microseconds

Timer Clock Accuracy 1 microsecond, Jitter 1 microsecond)"

-

"RTAI - the Realtime Linux Application Interface for Linux ... lets you write applications with strict timing constraints for your favourite operating system." -

"KURT-Linux: Kansas University Real-Time Linux: Microsecond timing resolution and event-driven real-time scheduling..." -

--
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
have an "impossible" engineering project that only someone like 
Doc Brown can solve?  My resume is at http://www.guymacon.com/

"What is RTAI?

RTAI means Real Time Application Interface. Strictly speaking, it is not a real time operating system, such as VXworks or QNX. It is based on the Linux kernel, providing the ability to make it fully pre-emptable. "

Your serve.

[BTW, isn't RTAI a kernel - a microkernel - all by itself ? You could say that this isn't actually Linux. Linux runs essentially as a process above RTAI. This isn't necessary in an OS such as, for example, Greenhills Integrity, which provides guaranteed latency and other goodies.]

--

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