Jan Kiszka referred me to you discussing our problem with a missing Ipipe hook at system call exit.
We at Siemens A&D do have a Linux realtime approach which is based on a previous ADEOS version. When trying to port an improved version to the Ipipe version for kernel 126.96.36.199 we ran into the problem of not having an event hook at system call exit. Let me explain the need for it by briefly outlining our approach.
It is a two kernel approach based on the model of a multihreaded process (means 2.6 kernel) where the threads above a certain static priority level e.g. 68 are scheduled by the scheduler of the realtime kernel. The realtime kernel maintains exactly the same systemcall interface as the Linux kernel. The entire process works uniformely with the glibc. The glibc isn't aware under which scheduler the current thread is executing. To make this happen and having both schedulers to work with the same struct task struct we had to put some restrictions on the signalling for the realtime domain (restrictions which make sense for the realtime arena anyway). Because of that transparency this approach combines somehow the advantages of a separated realtime kernel with the user convenience of PREEMPT_RT. (the user convenience was the driving requirement for our approach)
Now to the question why we need a hook at systemcall exit.
The hook at systemcall entry branches to the system call handling of the realtime kernel, which is also entered via a systemcall table. The handling can be grouped in three classes
- complete handling in the realtime domain e.g. timer_settime(), sigwait()
- only migration of the thread to the Linux scheduler. Basically all calls needed for setup e.g. open(), mmap(), pthread_create(). The migration is transparent for the ipipe code, the thread continues execution in the Linux domain with the call of the Linux system call table (the priority hasn't changed).
- handling in the realtime domain and migration to the Linux domain if the thread priority has dropped unter the boundary (e.g releasing a mutex with priority ceiling)
In particular for the second case a check needs to be done at sytem call exit as to whether the thread has to migrate (back) to the realtime scheduler. But this is also needed when a call issued in the Linux raises the priority above the threshold. A third reason for the hook is to touch the corresponding pages after a brk() or mmap() call for getting residency.
The migration only takes place for threads of a process marked as realtime.
Currently we allow only for one realtime process. First it is sufficient for us and second it allows us to maintain the futex queue (each domain maintains a local queue) of the realtime domain with virtual addresses (no mm_lock).
So this hook at system call exit is a necessity for us. Of course we could do a private patch, but do you see a possibility to have it in the standard Ipipe-patch?
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core