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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to