On Tue, Jul 28, 2020 at 1:57 PM David Ahern <dsahern@xxxxxxxxx> wrote: > > 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. I don't believe that's all we can do. Designing APIs that are less error-prone is at least one way to go about that. One can find plenty of examples where well-documented and standardized APIs are nevertheless misused regularly. Also, "users read and follow documentation" doesn't match my experience, unfortunately.
