From: Kent Gibson <warthog618@gmail.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Darrien <darrien@freenet.de>,
Viresh Kumar <viresh.kumar@linaro.org>, Jiri Benc <jbenc@upir.cz>,
Joel Savitz <joelsavitz@gmail.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: Re: [libgpiod v2][PATCH v2 5/5] bindings: python: add the implementation for v2 API
Date: Fri, 1 Jul 2022 16:52:15 +0800 [thread overview]
Message-ID: <20220701085215.GA35727@sol> (raw)
In-Reply-To: <CAMRc=MdMSwbikyZZDVayd_HZ3B=nAA2ZFXhMh5v0quT5nsYoHQ@mail.gmail.com>
On Fri, Jul 01, 2022 at 10:32:30AM +0200, Bartosz Golaszewski wrote:
> On Fri, Jul 1, 2022 at 10:18 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
....
> > > > >
> > > > > Timedelta constructor is much more explicit than a float IMO. How
> > > > > about a compromise and taking both (mutually exclusive)?
> > > > > timeout=datettime.timedelta(seconds=1) == timeout_sec=float(1.0)?
> > > > >
> > > >
> > > > Maybe, but float seconds seems to be the way they do it.
> > > > If you insist on both then just the one timeout parameter and work the
> > > > type out on the fly. (it's Python, so dynamic typing...)
> > > >
> > >
> > > Same issue for chip.wait_info_event(), btw.
> > > Still working through a full review - but it'll probably take a while.
> > >
> > > Wrt the wait, does the C API have a blocking wait, or do you have to
> > > poll() the fd?
> > >
> >
> > Blocking wait is simply reading the event without checking if an event
> > is there to be read. select() (the system call) waits indefinitely if
> > the timeval struct is NULL, ppoll() behaves the same for a NULL
> > timespec, poll() does the same for a negative timeout (which is an
> > int). We take an uint64_t so we can't do it. Either we need to switch
> > to int64_t and interpret a negative value as indefinite wait or just
> > not do it at all and tell users to just call the (blocking)
> > read_edge_event().
> >
> > Bart
> >
>
> I'm still on the fence about using timespec. It seems that the more
> recent linux interfaces avoid timespec and timeval altogether due to
> the year 2038 problem and the subsequent change in the struct layout.
> On the other hand the timeouts are unlikely to be set to years. :)
>
> What do you think?
>
I prefer not using timespecs. I prefer the int64 microseconds/nanoseconds
or float seconds approaches.
Especially for the time scales we are concerned with.
I only use timespecs where existing APIs such as ppoll() require it.
For the C API I'd go with int64 nsec, for Python float secs.
(though as already covered - with Python you could accept float
secs, int nsec, or a timedelta all in the one parameter)
Cheers,
Kent.
next prev parent reply other threads:[~2022-07-01 8:52 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 8:42 [libgpiod v2][PATCH v2 0/5] bindings: implement python bindings for libgpiod v2 Bartosz Golaszewski
2022-06-28 8:42 ` [libgpiod v2][PATCH v2 1/5] bindings: python: remove old version Bartosz Golaszewski
2022-06-28 8:42 ` [libgpiod v2][PATCH v2 2/5] bindings: python: enum: add a piece of common code for using python's enums from C Bartosz Golaszewski
2022-06-28 8:42 ` [libgpiod v2][PATCH v2 3/5] bindings: python: add examples for v2 API Bartosz Golaszewski
2022-06-28 8:42 ` [libgpiod v2][PATCH v2 4/5] bindings: python: add tests " Bartosz Golaszewski
2022-07-05 2:08 ` Kent Gibson
2022-07-07 10:17 ` Bartosz Golaszewski
2022-07-07 12:22 ` Kent Gibson
2022-06-28 8:42 ` [libgpiod v2][PATCH v2 5/5] bindings: python: add the implementation " Bartosz Golaszewski
2022-06-30 2:25 ` Kent Gibson
2022-06-30 6:54 ` Bartosz Golaszewski
2022-06-30 8:14 ` Kent Gibson
2022-06-30 8:38 ` Kent Gibson
2022-07-01 6:07 ` Kent Gibson
2022-07-01 7:21 ` Bartosz Golaszewski
2022-07-01 7:26 ` Kent Gibson
2022-07-01 7:29 ` Bartosz Golaszewski
2022-07-01 7:33 ` Kent Gibson
2022-07-01 8:02 ` Kent Gibson
2022-07-01 8:18 ` Bartosz Golaszewski
2022-07-01 8:32 ` Bartosz Golaszewski
2022-07-01 8:52 ` Kent Gibson [this message]
2022-07-01 9:28 ` Bartosz Golaszewski
2022-07-01 8:32 ` Kent Gibson
2022-07-05 2:09 ` Kent Gibson
2022-07-07 12:19 ` Bartosz Golaszewski
2022-07-07 13:09 ` Kent Gibson
2022-07-07 20:09 ` Bartosz Golaszewski
2022-07-08 1:38 ` Kent Gibson
2022-07-08 9:49 ` Bartosz Golaszewski
2022-07-08 10:56 ` Kent Gibson
2022-07-08 11:28 ` Bartosz Golaszewski
2022-07-08 15:26 ` Bartosz Golaszewski
2022-07-08 15:58 ` Kent Gibson
2022-06-28 8:47 ` [libgpiod v2][PATCH v2 0/5] bindings: implement python bindings for libgpiod v2 Bartosz Golaszewski
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=20220701085215.GA35727@sol \
--to=warthog618@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@bgdev.pl \
--cc=darrien@freenet.de \
--cc=jbenc@upir.cz \
--cc=joelsavitz@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=viresh.kumar@linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.