Re: [RESEND PATCH v6 6/7] gpiolib: add new ioctl() for monitoring changes in line info

[Bartosz Golaszewski]

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