Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Philippe Gerum wrote:
> On Wed, 2010-04-14 at 09:37 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>> The steps now:
>>>>>
>>>>> - we implement the automatic switchback of shadow nrt threads to
>>>>> secondary mode, upon return from Xenomai (primary) syscalls. I am
>>>>> working on this. The most significant impact is on userland, due to the
>>>>> fastsynch support, actually. Kernel-wise, it's rather straightforward.
>>>>> The only exception to this would be when the caller owns an exclusive
>>>>> resource (like a mutex), in which case the mode downgrade should be
>>>>> postponed until the syscall releasing the last resource held returns.
>>>> Kernel is clear, but user space sounds indeed interesting. I guess we
>>>> need an out-of-band channel to tell the kernel about pending
>>>> user-space-only lock ownerships when calling some unrelated syscall. How
>>>> does your current approach look like?
>>> I want to keep things simple: shadow nrt will go through the syscalls
>>> for acquisition/release of owned resources, instead of fastsynchs.
>> Then I'll have to pick this up as that will very likely create unhappy
>> customers. In fact, the majority of our Xenomai threads are nrt (yeah,
>> that happens if you convert existing applications).
> 
> I would understand that people do not want to bother that much with
> using the right kind of threads between shadow nrt and plain linux
> within the context of an initial port, but at some point, the code
> should be made consistent with respect to the real use.
> 
> If there is a problem with auto-shadowing in the POSIX skin, or
> sched_setscheduler() or whatever, then it should be addressed, but we
> just can't pile up code only to satisfy such a corner case, i.e.
> situations where applications create Xenomai nrt threads without actual
> need for this, to make them run in secondary mode only, without
> requiring a single primary-mode service (hence wanting hard to keep
> __xn_exec_current for RTDM).
> 
> So, I will merge the bits I have in mind as a first step, because they
> satisfy the normal usage of Xenomai threads. I will certainly ACK any
> improvement to this code which keeps the original fastsynch optimization
> for nrt threads, provided the feature/code overhead ratio seems correct.

I agree. Let us have your solution merged first, to get to a less
troublesome situation (my concern is about switchtest, I am a bit
selfish, but switchtest just helped me again solving FPU issues).

Optimizations can be taken care of later, especially when we are talking
about optimization of shadowed non real-time threads, good performances
for them is a nice-to-have, not our primary concern.

-- 
					    Gilles.