* Re: [Xenomai-help] Linux system calls from RT kernel task
2007-04-12 13:18 ` Jeff Weber
@ 2007-04-12 14:05 ` Philippe Gerum
2007-04-12 14:24 ` Gilles Chanteperdrix
1 sibling, 0 replies; 7+ messages in thread
From: Philippe Gerum @ 2007-04-12 14:05 UTC (permalink / raw)
To: Jeff Weber; +Cc: Xenomai help
On Thu, 2007-04-12 at 08:18 -0500, Jeff Weber wrote:
> On Wednesday 11 April 2007 17:35, Dmitry Adamushko wrote:
> > On 11/04/07, Jeff Weber <jweber@domain.hid> wrote:
> > > Are there any restrictions against calling the Linux kernel, namely
> > > do_gettimeofday(), from a Xenomai kernel task?
> > >
> > > Does the kernel space task switch from primary to secondary mode, just as
> > > a user space task would?
> >
> > No.
> Ok, so is a Xenomai kernel-based thread essentially locked into primary mode?
Basically, secondary mode does not exist for kernel threads, so the
answer is yes.
The best way to understand this is to get back to the way kernel-based
Xenomai threads are implemented: they are pure Xenomai abstractions
running as some kind of in-kernel co-routines, which are _not_ based on
Linux kernel threads (i.e. task_structs). As a consequence of this, the
regular Linux scheduler does not even know about them, and in any case,
can't schedule them. For this reason, only the Xenomai scheduler is able
to control those threads, and as such, those are essentially primary
mode things. In that sense, a task runs in primary mode because it is
controlled by the Xenomai scheduler, and switches to secondary mode as a
result of its control being transferred to the regular Linux scheduler.
Another hint to figure out why this works this way is to consider how
modes are switched between primary and secondary for any given Xenomai
thread: such switching occurs at the syscall interface level in kernel
space, right after the user-space to kernel transition. IOW, right now,
the secondary mode can only be defined for tasks having a user-space
side.
This implementation (i.e. the way kernel-based Xenomai threads are
defined) will change in Xenomai 3 when running over a fully preemptible
kernel, but this is likely to stay as it is when used in co-kernel mode.
>
> And if so, would calls to rt_task_set_mode(T_PRIMARY,0,0) then be illegal?
You would get -EINVAL.
> >
> > Regarding the use of Linux kernel functions, consider it from the
> > point that your rt task (in general, any activity from the primary
> > domain) could have interrupted the Linux kernel at any (well, almost)
> > point.. i.e. some spin_locks can be held by the kernel and if you
> > happen to call a function from the primary domain that does use these
> > locks - well, nothing good is going to happen. In general, it's a no
> > go.
> What's the best general way to describe the list of functions that can use
> these locks, so I can avoid this scenario in the future?
>
In short, any activity which is currently controlled by the regular
Linux core:
1) any regular Linux thread, user-space or kernel-based created outside
the Xenomai realm.
2) any user-space Xenomai thread running in secondary mode (vs all
kernel-based Xenomai threads and user-space Xenomai threads running in
primary mode).
3) any Linux interrupt handler when the kernel logic allows this (vs
interrupt handlers installed by Xenomai to process real-time events).
4) any asynch callbacks fired by the regular kernel, like softirqs etc.
Xenomai APCs (asynch procedure calls) also belong to this category,
since Xenomai delegates their handling to Linux, which in turn fires
them as soon as possible when it is back in control of the hardware (vs
strict real-time operation mode).
Anything outside of this list cannot use these locks without leading to
"unexpected results".
> Jeff
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai-help] Linux system calls from RT kernel task
2007-04-12 13:18 ` Jeff Weber
2007-04-12 14:05 ` Philippe Gerum
@ 2007-04-12 14:24 ` Gilles Chanteperdrix
2007-04-12 14:57 ` Jeff Weber
1 sibling, 1 reply; 7+ messages in thread
From: Gilles Chanteperdrix @ 2007-04-12 14:24 UTC (permalink / raw)
To: Jeff Weber; +Cc: Xenomai help
Jeff Weber wrote:
> On Wednesday 11 April 2007 17:35, Dmitry Adamushko wrote:
>
>>On 11/04/07, Jeff Weber <jweber@domain.hid> wrote:
>>
>>>Are there any restrictions against calling the Linux kernel, namely
>>>do_gettimeofday(), from a Xenomai kernel task?
>>>
>>>Does the kernel space task switch from primary to secondary mode, just as
>>>a user space task would?
>>
>>No.
>
> Ok, so is a Xenomai kernel-based thread essentially locked into primary mode?
> And if so, would calls to rt_task_set_mode(T_PRIMARY,0,0) then be illegal?
>
>>Regarding the use of Linux kernel functions, consider it from the
>>point that your rt task (in general, any activity from the primary
>>domain) could have interrupted the Linux kernel at any (well, almost)
>>point.. i.e. some spin_locks can be held by the kernel and if you
>>happen to call a function from the primary domain that does use these
>>locks - well, nothing good is going to happen. In general, it's a no
>>go.
>
> What's the best general way to describe the list of functions that can use
> these locks, so I can avoid this scenario in the future?
The problem does not come only from locks. Real-time tasks can preempt
Linux at any time, and particularily at times when Linux data is not
consistent. So, if you want to play safe, do not use Linux kernel
functions from real-time kernel threads, only use Xenomai services (for
instance, the Xenomai service for getting the current date is
rt_timer_read or clock_gettime(CLOCK_REALTIME)). The exception to this
rule is printk.
--
Gilles Chanteperdrix
^ permalink raw reply [flat|nested] 7+ messages in thread