Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Gilles Chanteperdrix
Jan Kiszka wrote: > Am 05.10.2010 15:50, Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Am 05.10.2010 15:42, Gilles Chanteperdrix wrote: Jan Kiszka wrote: > Am 05.10.2010 15:15, Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Hi, >>> >>> quite a few limitations a

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Jan Kiszka
Am 05.10.2010 15:50, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Am 05.10.2010 15:42, Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: Am 05.10.2010 15:15, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Hi, >> >> quite a few limitations and complications of using Li

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Gilles Chanteperdrix
Jan Kiszka wrote: > Am 05.10.2010 15:42, Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Am 05.10.2010 15:15, Gilles Chanteperdrix wrote: Jan Kiszka wrote: > Hi, > > quite a few limitations and complications of using Linux services over > non-Linux domains relate to potent

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Jan Kiszka
Am 05.10.2010 15:42, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Am 05.10.2010 15:15, Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: Hi, quite a few limitations and complications of using Linux services over non-Linux domains relate to potentially invalid "current" and

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Gilles Chanteperdrix
Jan Kiszka wrote: > Am 05.10.2010 15:15, Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Hi, >>> >>> quite a few limitations and complications of using Linux services over >>> non-Linux domains relate to potentially invalid "current" and >>> "thread_info". The non-Linux domain could maintain t

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Jan Kiszka
Am 05.10.2010 15:15, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Hi, >> >> quite a few limitations and complications of using Linux services over >> non-Linux domains relate to potentially invalid "current" and >> "thread_info". The non-Linux domain could maintain their own kernel >> stacks

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Gilles Chanteperdrix
Jan Kiszka wrote: > Hi, > > quite a few limitations and complications of using Linux services over > non-Linux domains relate to potentially invalid "current" and > "thread_info". The non-Linux domain could maintain their own kernel > stacks while Linux tend to derive current and thread_info from

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Jan Kiszka
Am 05.10.2010 13:06, Jan Kiszka wrote: > Am 05.10.2010 12:59, Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> My key question is currently if and how much of this could be realized >>> in 2.6. Could we drop in-kernel skins in that version? If not, what >>> about disabling them by default, conv

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Jan Kiszka
Am 05.10.2010 12:59, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> My key question is currently if and how much of this could be realized >> in 2.6. Could we drop in-kernel skins in that version? If not, what >> about disabling them by default, converting RTDM tasks to a >> kthread-based appro

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Gilles Chanteperdrix
Jan Kiszka wrote: > My key question is currently if and how much of this could be realized > in 2.6. Could we drop in-kernel skins in that version? If not, what > about disabling them by default, converting RTDM tasks to a > kthread-based approach, and enabling tracing etc. only in that case? > How

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Gilles Chanteperdrix
Jan Kiszka wrote: > Am 05.10.2010 12:32, Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> - consistent view on the system (if current is always valid, there are >>>no more confusions between current Linux vs. Xenomai task) >> That is inherently incompatible with the co-kernel approach. Xen

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Jan Kiszka
Am 05.10.2010 12:32, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> - consistent view on the system (if current is always valid, there are >>no more confusions between current Linux vs. Xenomai task) > > That is inherently incompatible with the co-kernel approach. Xenomai > will always be

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Gilles Chanteperdrix
Jan Kiszka wrote: > - consistent view on the system (if current is always valid, there are >no more confusions between current Linux vs. Xenomai task) That is inherently incompatible with the co-kernel approach. Xenomai will always be able to preempt Linux at a place where the state is not co

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Jan Kiszka
Am 05.10.2010 11:56, Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Hi, >> >> quite a few limitations and complications of using Linux services over >> non-Linux domains relate to potentially invalid "current" and >> "thread_info". The non-Linux domain could maintain their own kernel >> stacks

Re: [Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Gilles Chanteperdrix
Jan Kiszka wrote: > Hi, > > quite a few limitations and complications of using Linux services over > non-Linux domains relate to potentially invalid "current" and > "thread_info". The non-Linux domain could maintain their own kernel > stacks while Linux tend to derive current and thread_info from

[Xenomai-core] Overcoming the "foreign" stack

2010-10-05 Thread Jan Kiszka
Hi, quite a few limitations and complications of using Linux services over non-Linux domains relate to potentially invalid "current" and "thread_info". The non-Linux domain could maintain their own kernel stacks while Linux tend to derive current and thread_info from the stack pointer. This is not