Re: [Xenomai-core] [PATCH-STACK] Synchronised timebases and more

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]

Philippe Gerum wrote:
> On Thu, 2007-06-21 at 09:58 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> If you think of it, decoupling only requires to keep a constant epoch
>>> (at least one the nucleus does not update) somewhere within the timebase struct,
>>> the user code could wire to some value when it sees fit (e.g. pSOSish tm_set(),
>> I know. It should be simple.
>>
>>> or VRTX's sc_stime() and so on). Obtaining a so-called constant-based time would have
>>> then to be available through an additional method, returning constant_epoch + delta,
>>> whatever delta means wrt aperiodic/periodic behaviour. The point here is that we
>>> would just shift the constant epoch - decorrelated from system time - from default
>>> xntbase_get_time() behaviour to something which should be explicitly requested
>>> through a new specialized timebase method if needed.
>> Well, that's precisely the set of new conversion functions I'm a bit
>> afraid of. But as it now comes with the "special case", not the default
>> one, I would be fine with it.
>>
> 
> Indeed, it's really about shifting the default behaviour to synchronized
> timebases. There is not much harm to expect from using specialized
> services to get a constant-based timebase anyway, since only skin
> developers would need that, and those people ought to know what they are
> doing.

Nope, it's a user thing: The user has to convert timestamps from one
skin (e.g. an RTDM device) into his own or vice versa. That makes it so
critical.

> 
>>> IOW, introducing synchronized timebases is not the issue, making timebase
>>> synchronization the default behaviour is what has some importance here.
>> I predict it will save all of us from headache, at least from more
>> headache than with the other way around. :)
>>
> 
> Ok, let's go for it, the changes are easily identifiable. I guess that
> is something we could not postpone to 2.5 anyway. I want to merge this
> asap now, because I don't want to delay -rc1 anymore, and the merge
> window is almost closed.
> 
> Actual uses of this feature - e.g. POSIX resync - should go into -rc2,
> unless they are (almost) ready for merge right now.
> 

Do you already have an idea about the "decoupling API"? Or should we
postpone this to -rc2 as well? Same for resync as a generic xntbase feature.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]