Gilles Chanteperdrix wrote:
> 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.

Then even more fixing is required here:

#define T_BLOCKED  XNPEND     /**< See #XNPEND    */
...

Will take the chance.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to