On 7/28/20 11:15 PM, Andrii Nakryiko wrote: > 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. > This API is about exposing a standard, well-known clock source to bpf programs. Your argument is no because some users might use it incorrectly, and I think that argument is wrong. Don't make people who know what they are doing jump through hoops because a novice might make a mistake.
