On 7/28/20 12:28 PM, Andrii Nakryiko wrote: > In some, yes, which also means that in some other they can't. So I'm > still worried about misuses of REALCLOCK, within (internal daemons > within the company) our outside (BCC tools and alike) of data centers. > Especially if people will start using it to measure elapsed time > between events. I'd rather not have to explain over and over again > that REALCLOCK is not for measuring passage of time. Why is documenting the type of clock and its limitations not sufficient? Users are going to make mistakes and use of gettimeofday to measure time differences is a common one for userspace code. That should not define or limit the ability to correctly and most directly do something in bpf. I have a patch to export local_clock as bpf_ktime_get_fast_ns. It too can be abused given that it has limitations (can not be used across CPUs and does not correlate to any exported clock), but it too has important use cases (twice as fast as bpf_ktime_get_ns and useful for per-cpu delta-time needs). Users have to know what they are doing; making mistakes is part of learning. Proper documentation is all you can do.
