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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3620 bytes --]

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).

The scenario is not that simple - unfortunately.

> 
> 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.

Fine with me.

>>>>  For the use case of an enforced primary
>>>> mode switch-back, add a new service - if it is really required.
>>>> rt_task_set_mode is about static property switching, so adding T_PRIMARY
>>>> here was already a bad idea from that perspective.
>>>>
>>> There is no such limitation to rt_task_set_mode(), and T_CONFORMING is
>>> not meant to be used blindly. So, I will stick with this interface.
>> T_CONFORMING is a mini-me of T_PRIMARY. If we already clean up the
>> latter, it is a unique chance to finally drop that misplaced interface
>> from rt_task_set_mode. It's asymmetric and does not really fit into the
>> "true" modes that this interface controls.
>>
> 
> So, basically T_LOCK is a static switch for you? You mean that locking
> the scheduler is a static property of any thread? Same for T_NOSIG and
> blocking asynchronous calls? Look, I designed this interface after the
> pSOS equivalent, and I can assure you that this was indeed meant to be a
> mean to control dynamic properties.

Those modes are not static but they can be applied symmetrically and do
not change due to other influences.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]