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

The idea is not to remove the service, but rather to make perfectly clear that
such feature is not for normal usage. I did agree a long time ago that it could
be needed by low-level skin code when Jan asked for it, but I'm against its
widespread use.

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

It should be kept, but moved out from the mainline API, only accessible via a
direct XENOMAI_SYS() call, not using a high level interface such as
rt_task_set_mode(). The message should be: this is an internal service for skin
developers, if you need it for regular application code, then something looks
broken in your code. Userland code that implements extended debugging facilities
or any kind of tricky instrumentation feature would still be allowed to call the
direct interface, but at least, this would not be done carelessly anymore.


Xenomai-core mailing list

Reply via email to