Getting hardware interrupt in user-space program

sundialsvcs · 08-04-2015, 09:46 AM

A context-switch takes very little resources, actually. The interrupt can activate a very high priority process, in userland, which gathers information and/or sends it, and there will be very little "latency" involved. This process might, in turn, signal other client processes, also in userland.

jpollard · 08-04-2015, 11:02 AM

yes. The advantage is not wasting application time (and code) doing what the kernel already does.

shekharrana · 08-04-2015, 12:06 PM

@david_8274,
"--- if the blocking read is in thread_1, doesn't the user-space program have to first go back to thread_1 before the blocking read gets the interrupt? If the program doesn't do context switching constantly, how does thread_1 gets the interrupt?"

constant cont_switching is not required. when in ISR u invoke wake_up_interruptible(), it will set the TIF NEED_RESCHED flag => on exits from ISR i.e. "rfi", scheduler() would be invoked and context switch could happen.
So your thread_1 will get CPU.
Hope that clarifies...

david_8274 · 08-04-2015, 12:45 PM

Quote:

Originally Posted by shekharrana

@david_8274,
"--- if the blocking read is in thread_1, doesn't the user-space program have to first go back to thread_1 before the blocking read gets the interrupt? If the program doesn't do context switching constantly, how does thread_1 gets the interrupt?"

constant cont_switching is not required. when in ISR u invoke wake_up_interruptible(), it will set the TIF NEED_RESCHED flag => on exits from ISR i.e. "rfi", scheduler() would be invoked and context switch could happen.
So your thread_1 will get CPU.
Hope that clarifies...

@shekharrana
Thank you for the clarification. Then I think this is the way to go -- create a queue and use wait_event_interruptible() and wake_up_interruptible() to catch the event.

Wei

jpollard · 08-04-2015, 06:26 PM

Quote:

Originally Posted by david_8274

@shekharrana
Thank you for the clarification. Then I think this is the way to go -- create a queue and use wait_event_interruptible() and wake_up_interruptible() to catch the event.

Wei

Only if you are writing device drivers...

This only works in kernel mode.

sundialsvcs · 08-04-2015, 08:51 PM

I personally think that the best strategy is to go to user-land, and to make sure that the next user-land process to get control of the CPU is the special-purpose one that you want.

shekharrana · 08-05-2015, 01:49 AM

Quote:

Originally Posted by jpollard

Only if you are writing device drivers...

This only works in kernel mode.

with either approaches (waitqueue or send_signal), things shall be modified in kernel aswell as userland.

would be nice to hear another approach without tweaking in kernel!!

jpollard · 08-05-2015, 05:56 AM

Quote:

Originally Posted by shekharrana

with either approaches (waitqueue or send_signal), things shall be modified in kernel aswell as userland.

would be nice to hear another approach without tweaking in kernel!!

There are lots of ways.

select, epoll, semaphores, sockets, read/write, threads, shared memory, dbus, ...

Userspace has lots of tools, and are (for the most part) relatively easy to debug. Granted, it does get more complex as you add more parallel activity.

sundialsvcs · 08-05-2015, 06:46 AM

Another common technique is to write a virtual device type, which gives you the "read/write/ioctl" interface that can be used by any userland program. As well as oodles of examples of how to do it, in existing kernel source-code. The whole thing can be bundled as a loadable kernel module.