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 an
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 the stack
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 while Linux tend
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
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?
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 approach, and
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, converting RTDM
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 the stack
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 their own kernel
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
thread_info. The
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 potentially invalid current and
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 and complications of using Linux services
12 matches
Mail list logo
