What you would have to do is something like
1. Linux process mlocks, and then calls rtl_register_task(function pointer)
event (e.g. timer irq)
rtl_irq handler
call rtl_scheduler
find rtl task to run
rtl task does switch to user mode at addr -- into linux process
The whole point is to avoid a Linux process switch -- and the attendent delays
So current points to the current linux process, but that may be waiting for
the realtime process.
> Why not move the process to a Linux run queue on kernel traps? This
It would be easy for the "parent" RT context to do this.
> > But it would require a bigger Linux patch.
>
> Indeed.
>
> > I described this idea to Linus and it made him deeply unhappy.
>
> Precisely what made him unhappy? The requirement to patch all kernel
> entry and exit points? Or just the concept of dropping RTL priority?
I suspect it was the extra glop on the kernel: but Californians are a mystery to
me. I'm not so thrilled with the idea either.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/