Dmitry Adamushko wrote:
> Hi,
> 
> 
> given the existing doc of rt_task_suspend about allowed environments and
>> also when thinking about the logic behind it, I see no reason why
>> xnpod_unblockable_p() is also applied to task != NULL.
> 
> 
> 
> XNLOCK is set? anyway, I don't see how the patch makes current logic
> different...
> 
> in both cases xnpod_unblockable_p() has a chance to be executed only when
> task != NULL (thanks to goto). and -EPERM is returned when task != NULL &&
> xnpod_unblockable_p() == true.
> 
> 
>        if (!task) {
>>                 err = xeno_handle_error(task, XENO_TASK_MAGIC, RT_TASK);
>>                 goto unlock_and_exit;
>> -       }
>> -
>> -       if (xnpod_unblockable_p()) {
>> +       } else if (xnpod_unblockable_p()) {
>>                 err = -EPERM;
>>                 goto unlock_and_exit;
>>         }
>>
>>
>>
> 
> 

Oh, my dear. I should stop hacking patches while talking to colleagues.
Does this one make more sense?

Jan
Index: ksrc/skins/native/task.c
===================================================================
--- ksrc/skins/native/task.c    (revision 1323)
+++ ksrc/skins/native/task.c    (working copy)
@@ -391,9 +391,9 @@ int rt_task_start(RT_TASK *task, void (*
  *
  * - -EINVAL is returned if @a task is not a task descriptor.
  *
- * - -EPERM is returned if @a task is NULL but not called from a task
- * context, or this service was called from a context which cannot
- * sleep (e.g. interrupt, non-realtime or scheduler locked).
+ * - -EPERM is returned if @a task is NULL and this service was called
+ * from a context which cannot sleep (e.g. interrupt, non-realtime or
+ * scheduler locked).
  *
  * - -EIDRM is returned if @a task is a deleted task descriptor.
  *
@@ -432,7 +432,7 @@ int rt_task_suspend(RT_TASK *task)
                goto unlock_and_exit;
        }
 
-       if (xnpod_unblockable_p()) {
+       if (xnpod_locked_p()) {
                err = -EPERM;
                goto unlock_and_exit;
        }

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