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

>>> 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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to