czw., 20 lut 2020 o 16:03 Linus Walleij <linus.walleij@xxxxxxxxxx> napisał(a): > > On Wed, Feb 12, 2020 at 12:00 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > On Tue, Feb 11, 2020 at 10:19 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx> > > > > A question: > > > > > > Bartosz, since you know about possible impacts on userspace, > > > since this code use the preferred ktime_get_ns() rather than > > > ktime_get_ns_real(), what happens if we just patch the other > > > event timestamp to use ktime_get_ns() instead, so we use the > > > same everywhere? > > > > > > If it's fine I'd like to just toss in a patch for that as well. > > > > > > > Arnd pointed out it would be an incompatible ABI change[1]. > > Yeah, I was thinking more about this specific answer from Arnd: > > > "It is an incompatible ABI change, the question here is whether anyone > > actually cares. If nothing relies on the timestamps being in > > CLOCK_REALTIME domain, then it can be changed, the question > > is just how you want to prove that this is the case." > > So the question is if userspace really cares. > > What happens with libgpiod or users of it? Are they assuming > the weirdness of CLOCK_REALTIME, or are they simply assuming > something that is monotonic increasing and just lucky that they > didn't run into anything jumping backwards in time even though > they *could*. > > I think I'll propose a change and see what people say. > Libgpiod doesn't care about the value really - it just forwards whatever it reads. Bart > > However - I asked Khouloud who's working on v2 of the line event > > interface to use ktime_get_ns(). > > That's great! > > Yours, > Linus Walleij