Bernhard Walle wrote:
> Hello,
> 
> sorry for the late reply.
> 
> * Jan Kiszka <[EMAIL PROTECTED]> [2006-09-06 15:52]:
>> Bernhard Walle wrote:
>>> Hello,
>>>
>>> ,----
>>> | int rtdm_task_sleep (uint64_t delay);
>>> | int rtdm_task_sleep_until (uint64_t wakeup_time);
>>> `----
>>>
>>> wouldn't it make sense to return 0 on success and in error case the
>>> number of nanoseconds that are remaining to the originally requested
>>> sleep period just as the Linux sleeping function behave?
>> Do you have a use-case for this? Would you consider this as the normal
>> scenario?
> 
> I must confess that I don't have one. I just compared the Linux API
> with the RTDM API for that use case. I'll dig into sources of Linux
> drivers and see if there are reasonable use cases. But this may take
> some days as I'm a bit busy now.
> 
>> Also note that changing the return type would take away to possibility
>> to pass the error code.
> 
> Not really. You can
> 
>   < 0 : error code (in this case -EPERM)
>   == 0 : success
>   > 0 : remaining time
> 
> Or simple
> 
>   int rtdm_task_sleep(uint64_t delay, uint64_t *time_left);
> 
> That would make it more compatible with the current API since the user
> can simply replace
> 
>   ret = rtdm_task_sleep(delay);
> 
> with 
> 
>   ret = rtdm_task_sleep(delay, NULL);
> 
>>> Of course that would introduce an incompatibility to current code.
>> Given a reasonably urging use-case or brokenness of the original
>> interface, API revisions may actually take place in RTDM (see the
>> history). But they will surely not happen without thorough
>> considerations of pros and cons. :)
> 
> Because the missing information can be easily gathered from outside,
> it would be only worth changing if you plan some other changes in
> these functions so that this can be done in one in one step.
> 

You exactly hit the point. :->

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