Jeff Weber wrote:
> On Wednesday 11 April 2007 17:35, Dmitry Adamushko wrote:
>
>>On 11/04/07, Jeff Weber <[EMAIL PROTECTED]> 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
_______________________________________________
Xenomai-help mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/xenomai-help
