* Jan Kiszka <[EMAIL PROTECTED]> [2006-09-09 12:28]:
> This overwriting only takes place if timeout_seq is non-NULL. Otherwise,
> we are in "usual" timeout mode.

Yes, of course, you're right. It was too late when I wrote this mail.
I oversaw the NULL case.

> > Maybe
> > 
> >  * @param[in] timeout Relative timeout, see
> >  * @ref RTDM_TIMEOUT_xxx for special values (any positive value
> >  * means the timeout specified in the timeout sequence)
> > 
> > or something like that.
> No, that's wrong then. I guess we rather need something like this:
> "@param[in] timeout Relative timeout in nanoseconds, see @ref
> RTDM_TIMEOUT_xxx for special values; pass the overall timeout of the
> related series if timeout_seq is non-NULL"
> Does this help to clarify the situation? BTW, the same applies to
> rtdm_sem_timeddown and rtdm_mutex_timeddown, all of those could be
> combined in such a series.

Yes, that would make it clear.

> RTDM specification and development only take place over Xenomai, RTAI
> later adopts what we implement here. And this will quite likely remain
> so in the future. Therefore, the best place to discuss also abstract
> RTDM question is here, maybe later on a dedicated xenomai-drivers list
> when the traffic increases.
> For oddities of the RTAI implementation there is still the RTAI list
> where I'm subscribed as well and can jump in when required.

Ah, ok. Didn't know that you're subscribed, that's why I CC'd you.

OpenPGP Schl├╝ssel-ID: B69454FD (kurz) / E8951E8FB69454FD (lang)
Fingerprint: F3BE B2A7 8161 2986 ABA4  9AB9 E895 1E8F B694 54FD

Attachment: pgpFGcXfUWfz1.pgp
Description: PGP signature

Xenomai-core mailing list

Reply via email to