Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Just like it seems to be the case for Steve (unless I misunderstood his >>>> reply), it is very useful for us being able to time-stamp events in RT >>>> context that need to be correlated with events stamped in non-RT >>>> (including non-Xenomai) parts or even on other systems: (offline) data >>>> fusion, logging, tracing. I even bet that this is currently the major >>>> use case for synchronized clocks, only a smaller part already has the >>>> need to synchronize timed activities on a common clock source. But there >>>> is huge potential in the second part once we can provide a stable >>>> infrastructure. >>> I already had such issues, and I did not solve them by modifying Xenomai >>> core. >>> >>>> Even a "third clock" would have to be delivered for more archs than x86, >>>> no question. We would basically need a generic but slow syscall variant >>>> and per-arch syscall-less optimizations (where feasible). >>> So, you would add a syscall which would becomre useless when you have >>> implemented synchronized clocks properly? Yet another reason for >>> avoiding this solution. >>> >> Could be "CLOCK_LINUX" - ie. no need for a new syscall. > > I am Ok for this solution (and now that I think about it, I wonder if we > did not already have this discussion). Anyway, I would go for > CLOCK_HOST_REALTIME, in case someone wants to implement > CLOCK_HOST_MONOTONIC. The advantage is that we can return EINVAL in the > timer_create or clock_settime calls, to indicate clearly that using this > clock for timing services is verboten. And when/if the full > synchronization is implemented, the ID simply becomes a #define.
okay, so let's pursue this path. Patches will follow. Best, Wolfgang _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
