0

Is there any (dirty)method to provoke context switching to specific process after specific ISR?

In normal situation, after an ISR, the process which was interrupted will keep running, and I have to wait the scheduler to pick that specific process. I want to switch to the specific process right away after the ISR.

Any advice will be great. Thanks!

user3498780
  • 89
  • 8
  • 1
    'In normal situation, after an ISR, the process which was interrupted will keep running' - no, not always, and making a thread/process ready upon a hardware interrupt does not need any (dirty)method, it's normal behaviour for drivers when an I/O operation is completed, usually using semaphore or event signaling and requesting a scheduler run upon return from interrupt state. – Martin James May 13 '18 at 09:44
  • 1
    If there is a core free, or if your waiting thread is of high enough priority to preempt whatever was running on the cores before the interrupt, your thread/process will be made running, rather than just ready. – Martin James May 13 '18 at 09:47

1 Answers1

2

Construct your driver so that the process has a thread blocking on suitable syscall (read(), ioctl()) with the ISR waking up that thread (because at least one byte became available for read()).

Then, make sure that thread has the highest priority possible, and preferably uses a realtime scheduler (SCHED_FIFO or SCHED_RR). In practice, if your process does not run with root privileges, you'll need to start the service with root privileges, setup the thread, then drop privileges; or give the binary executable CAP_SYS_NICE capability via e.g. setcap pe=CAP_SYS_NICE binary.

It is technically possible for the driver to also mess with the scheduling, but I would not do that. Anything that is so time-critical, should be done in the kernel ISR instead.

If you want to do it in userspace, because you don't want your code to be a derivative of the kernel and therefore GPL-licensed, you're on your own.

Nominal Animal
  • 38,216
  • 5
  • 59
  • 86