Re: [Xenomai-core] rt_task_info.status encoding

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> the documentation refers to the Native Task Status (T_*) when it comes
>> to documenting rt_task_info.status. That is not correct. That field
>> contains far more flags than T_* is describing and, even worse, comes
>> with two collisions: T_PRIMARY and T_JOINABLE are not reported by
>> rt_task_inquire, rather T_RELAX (!T_PRIMARY, arrrg...) and T_HELD.
>>
> 
> T_PRIMARY is NOT meant to be reported by rt_task_inquire(), and actually, its
> value was picked to collide, to reflect the fact that it was a one-way
> specifier. You can't use T_RELAX because what is needed is a bit to force a
> transition to primary mode using rt_task_set_mode(), which is the actual source
> of all uglinesses. Aside of this, the nucleus naturally wants a "relaxed state"
> bit, and would not get any help from a "primary mode" bit for threads.
> 
> We could have used a T_RELAX bit to clear in rt_task_set_mode() instead of
> T_PRIMARY to set, but unfortunately, such a negative logic would have been
> somewhat confusing to users, since what is provided is the secondary -> primary
> mode switch.
> 
> Sending back the current mode in rt_task_inquire() would lead to two additional
> issues:
> 1) if for some reason, we would like to switch the caller to secondary mode at
> some point to be able to provide a more complete status, the primary/secondary
> status returned would make no sense at all. The fact that we don't do it now
> does not preclude the need to do it in future releases.
> 2) rt_task_set_mode(..., T_PRIMARY) is already vastly misused in a number of
> applications, sometimes uselessly, most of the time in a way that event kills
> performances. Giving an interface to get back the current mode would close the
> loop, triggering a whole set of new terminally silly usage of that hack.
> Applications should NEVER use that feature, it was initially designed for
> internal code (i.e. RTDM if my memory serves me well). Actually, the more I
> think of it, the more I convinced that I'm going to slaughter this crap in 2.5,
> providing an internal syscall from the XENOMAI_SYS class instead for use only in
> proper contexts.
> 
> T_JOINABLE might be reported, though, that is a different story.
> 
>> I see two ways out of this:
>>
>>  a) Redirect the documentation to the nucleus thread state flags.
>>
> 
> Which means that the documentation of the skin depends on the implementation of
> the core. Bad idea.

We also have a difficulty: when pdf documentations are generated, the
nucleus and native skin documentation end up in different documents. So,
we can not redirect the native skin documentation to nucleus.

> 
>>  b) Redefine the numerical values of T_PRIMARY and T_JOINABLE (the spare
>>     bits are unused with the native skin), add missing but possibly
>>     interesting flags as T_-constants and ensure that T_PRIMARY and
>>     T_JOINABLE are correctly injected on rt_task_inquire from user
>>     space.
> 
> Maybe for T_JOINABLE. Gilles?

Ok for me.

As a side note, I happen to use pthread_set_mode_np to trigger manual
mode transitions: I do this before calling the "socket" service to
trigger rtnet socket creation in secondary mode, where it can call
safely the kernel allocation methods. So, I am not really in favor of
removing this service.

However, if this usage disappears, and if we fix the issue with mode
switches and mutexes, I am Ok with removing the voluntary mode switches,
as I agree that they can be misused.

-- 
					    Gilles.