Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> This series fixes the issues around rt_task_inquire I posted yesterday.
>>>>>>> Additionally, it introduces an analogous services pthread_inquire_np for
>>>>>>> the POSIX skin. That allows, among other things, to implement test cases
>>>>>>> for the upcoming fast xnsynch/mutex patches.
>>>>>> Ok. Since this applies only for debugging purpose, and displaying
>>>>>> whether a task is in primary mode may be use badly by users, maybe we
>>>>>> should make this service a shadow syscall, and not export any interface
>>>>>> to use it. This would further avoid duplication between the native and
>>>>>> posix skins.
>>>>> Debugging is not the holy, exclusive business of Xenomai hackers.
>>>>> The inquire services are useful in libraries as well, when you want to
>>>>> check if the caller complies to the call convention ("don't use in
>>>>> primary mode", "caller's priority must not exceed X" or whatever).
>>>>> That said, I'm open for unifying the code, maybe introducing some
>>>>> xnthread_inquire.
>>>> That would be much better than publishing an open interface to fiddle even 
>>>> more
>>>> with thread modes via rt_task_set_mode(). I would definitely merge that.
>>> Code refactoring is no problem, will work that out. I just want to keep
>>> the user interface.
>> Looking into this, I come to the conclusion that xnthread_inquire is
>> only then a gain if both rt_task_inquire and pthread_inquire_np use the
>> same data structure layout. And that means that both need to use the
>> same time encodings, not struct timespec vs. RTIME like it is now. That
>> would not be beautiful, but feasible (e.g. picking __u64 as type,
>> passing nanoseconds). Still, it does not yet convince me.
> The idea behind xnthread_inquire() is not about replacing rt_task_inquire()
> under the hood, but rather to get back only fundamental values, such as the
> current thread status, in order to determine whether XNRELAX is set or not for
> instance.
> XENOMAI_SYSCALL1(__xn_sys_inquire) => xnthread_inquire(xnpod_current_thread())

OK, slowly getting to your core. Assume we had __xn_sys_inquire, what
should it return, and what should we mask from rt_task_inquire, and do
we still want pthread_inquire_np.

But I really dislike this approach of artificially
complicating/crippling interfaces just to hide XNRELAX (I can't imagine
you have problems with the other information rt_task_inquire returns).


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to