From: Arnd Bergmann <arnd@arndb.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
linux-gpio@vger.kernel.org,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Clemens Gruber <clemens.gruber@pqgruber.com>,
Thierry Reding <thierry.reding@gmail.com>,
Peter Rosin <peda@axentia.se>,
Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [RFC] libgpiod public API reviews needed
Date: Mon, 22 Jan 2018 14:46:12 +0100 [thread overview]
Message-ID: <CAK8P3a1Skvm48sje8FNDPLYqyz9Lf8q0qX1QETWtyZTxuX4k1g@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdapAoZ-Gzkx+SwGkkWBmyfeBaAtv1KdJd-wj2dvBamYAQ@mail.gmail.com>
On Mon, Jan 22, 2018 at 1:02 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Jan 22, 2018 at 10:25 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Jan 22, 2018 at 9:21 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>>> /**
>>> * struct gpioevent_data - The actual event being pushed to userspace
>>> * @timestamp: best estimate of time of event occurrence, in nanoseconds
>>> * @id: event identifier
>>> */
>>> struct gpioevent_data {
>>> __u64 timestamp;
>>> __u32 id;
>>> };
>>>
>>> It is the same as is used for IIO. Inside the kernel this ultimately
>>> comes from ktime_get_real_ns();
>>
>> Ah, too bad, that already contains two mistakes:
>>
>> - on x86, the structures are incompatible between 32-bit and 64-bit
>> user space, as the former has no padding.
>
> Sigh yeah that's bad... I guess we will be saved by the 64bit
> word coming first in the struct? (with the security problem
> you mention appearing after the 32 bits in ID.)
The main problem is the size of the data: kfifo_copy_to_user()
can copy multiple records, and while the first one would
remain accessible correctly, the second record contains
garbage if the kernel adds 4 bytes of padding inbetween.
>> - 'real' timestamps are inconvenient because time may jump in
>> either direction. Time stamps should use 'monotonic' time, i.e.
>> ktime_get_ns().
>
> So what we have in IIO is that it is configurable what timestamp
> you get.
>
> I've been meaning to fix this by breaking their timestamping
> into lib/ and use the same configurability per-gpiochip for GPIO.
> I guess this is the time to actually do it and stop talking on
> my part :/
Ok, makes sense.
> They also use the same default timestamp though.
>
> commit bc2b7dab629a ("iio:core: timestamping clock selection support")
>
> The code is in IIO in drivers/iio/industrialio-core.c:
>
> /**
> * iio_get_time_ns() - utility function to get a time stamp for events etc
> * @indio_dev: device
> */
> s64 iio_get_time_ns(const struct iio_dev *indio_dev)
> {
> struct timespec tp;
>
> switch (iio_device_get_clock(indio_dev)) {
> case CLOCK_REALTIME:
> ktime_get_real_ts(&tp);
> break;
> case CLOCK_MONOTONIC:
> ktime_get_ts(&tp);
> break;
> case CLOCK_MONOTONIC_RAW:
> getrawmonotonic(&tp);
> break;
> case CLOCK_REALTIME_COARSE:
> tp = current_kernel_time();
> break;
> case CLOCK_MONOTONIC_COARSE:
> tp = get_monotonic_coarse();
> break;
> case CLOCK_BOOTTIME:
> get_monotonic_boottime(&tp);
> break;
> case CLOCK_TAI:
> timekeeping_clocktai(&tp);
> break;
> default:
> BUG();
> }
>
> return timespec_to_ns(&tp);
> }
> EXPORT_SYMBOL(iio_get_time_ns);
>
> Which clock is used is configured per-device in sysfs.
>
> It's pretty neat I think.
To be honest, I think this is overcomplicating things. While I
have a patch to change the interface names and make them
all ktime_get_*_ns(), most of these clocks make no sense
at all for a random user space interface, mainly because
I wouldn't trust user space programmers to make an
informed decision which of those seven to use.
Arnd
next prev parent reply other threads:[~2018-01-22 13:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-19 13:28 [RFC] libgpiod public API reviews needed Bartosz Golaszewski
2018-01-20 16:02 ` Clemens Gruber
2018-01-21 21:14 ` Bartosz Golaszewski
2018-01-21 15:49 ` Linus Walleij
2018-01-21 21:30 ` Bartosz Golaszewski
2018-01-21 22:18 ` Arnd Bergmann
2018-01-22 8:21 ` Linus Walleij
2018-01-22 9:25 ` Arnd Bergmann
2018-01-22 9:28 ` Arnd Bergmann
2018-01-22 11:02 ` Bartosz Golaszewski
2018-01-22 11:12 ` Arnd Bergmann
2018-01-23 15:14 ` Bartosz Golaszewski
2018-01-22 12:02 ` Linus Walleij
2018-01-22 13:46 ` Arnd Bergmann [this message]
2018-01-23 14:15 ` Ludovic Desroches
2018-01-23 15:05 ` Bartosz Golaszewski
2018-01-25 16:29 ` Bartosz Golaszewski
2018-01-26 7:35 ` Ludovic Desroches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK8P3a1Skvm48sje8FNDPLYqyz9Lf8q0qX1QETWtyZTxuX4k1g@mail.gmail.com \
--to=arnd@arndb.de \
--cc=andy.shevchenko@gmail.com \
--cc=brgl@bgdev.pl \
--cc=clemens.gruber@pqgruber.com \
--cc=lars@metafoo.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=peda@axentia.se \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).