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.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to