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
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
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
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: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
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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo