* [Xenomai-core] Sleep return value
@ 2006-09-06 13:41 Bernhard Walle
2006-09-06 13:52 ` Jan Kiszka
0 siblings, 1 reply; 5+ messages in thread
From: Bernhard Walle @ 2006-09-06 13:41 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
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?
Of course that would introduce an incompatibility to current code.
Regards,
Bernhard
--
Ich denke, es gibt weltweit einen Markt für vielleicht fünf Computer.
-- Thomas Watson, Vorsitzender von IBM (1943)
[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] Sleep return value
2006-09-06 13:41 [Xenomai-core] Sleep return value Bernhard Walle
@ 2006-09-06 13:52 ` Jan Kiszka
2006-09-09 1:07 ` Bernhard Walle
0 siblings, 1 reply; 5+ messages in thread
From: Jan Kiszka @ 2006-09-06 13:52 UTC (permalink / raw)
To: Bernhard Walle; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
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?
Also note that changing the return type would take away to possibility
to pass the error code.
>
> 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. :)
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] Sleep return value
2006-09-06 13:52 ` Jan Kiszka
@ 2006-09-09 1:07 ` Bernhard Walle
2006-09-09 10:28 ` Jan Kiszka
0 siblings, 1 reply; 5+ messages in thread
From: Bernhard Walle @ 2006-09-09 1:07 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]
Hello,
sorry for the late reply.
* Jan Kiszka <jan.kiszka@domain.hid> [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.
Regards,
Bernhard
--
Bei der Eroberung des Weltraums sind zwei Probleme zu lösen: die Schwerkraft
und der Papierkrieg. Mit der Schwerkraft wären wir fertig geworden.
-- Wernher von Braun
[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] Sleep return value
2006-09-09 1:07 ` Bernhard Walle
@ 2006-09-09 10:28 ` Jan Kiszka
2006-09-09 10:58 ` Bernhard Walle
0 siblings, 1 reply; 5+ messages in thread
From: Jan Kiszka @ 2006-09-09 10:28 UTC (permalink / raw)
To: Bernhard Walle; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]
Bernhard Walle wrote:
> Hello,
>
> sorry for the late reply.
>
> * Jan Kiszka <jan.kiszka@domain.hid> [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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] Sleep return value
2006-09-09 10:28 ` Jan Kiszka
@ 2006-09-09 10:58 ` Bernhard Walle
0 siblings, 0 replies; 5+ messages in thread
From: Bernhard Walle @ 2006-09-09 10:58 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
* Jan Kiszka <jan.kiszka@domain.hid> [2006-09-09 12:28]:
> > 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. :->
Yes, I should first think and then post.
Regards,
Bernhard
--
OpenPGP Schlüssel-ID: B69454FD (kurz) / E8951E8FB69454FD (lang)
Fingerprint: F3BE B2A7 8161 2986 ABA4 9AB9 E895 1E8F B694 54FD
[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-09-09 10:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-06 13:41 [Xenomai-core] Sleep return value Bernhard Walle
2006-09-06 13:52 ` Jan Kiszka
2006-09-09 1:07 ` Bernhard Walle
2006-09-09 10:28 ` Jan Kiszka
2006-09-09 10:58 ` Bernhard Walle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.