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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
