From: Linus Walleij <linus.walleij@linaro.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>, Arnd Bergmann <arnd@arndb.de>
Cc: 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: Sun, 21 Jan 2018 16:49:01 +0100 [thread overview]
Message-ID: <CACRpkdb9JRsL1UFZ0+ipPmhYjd01Gy8+dL7yQ2RTkHJJdhf20w@mail.gmail.com> (raw)
In-Reply-To: <CAMRc=Md09CAQMS=5b7EUeh5AOjJ-zzbnETb_V+RdsxxafVxPdA@mail.gmail.com>
On Fri, Jan 19, 2018 at 2:28 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> I want to commit to a stable interface for the library starting from
> v1.0 but it would be great if I could get some reviews first - it's
> basically only about reviewing a single public header: include/gpiod.h
I have no real objections, then, I'm not a great API designer at all.
- In my opinion, all design should consider Rusty Russell's design
manifesto:
http://sweng.the-davies.net/Home/rustys-api-design-manifesto
Just ask yourself the questions in the manifesto to the function
signature.
- Things named with the infix "simple" *_simple_* *SIMPLE* etc.
This is a weasel word.
https://en.wikipedia.org/wiki/Weasel_word
I have been adviced against ever using that in code, because the
idea of what is "simple" is extremely subjective. A function with
six obscure parameters, is that "simple"?
I would have called it *rudimentary*, *coarse"* or *plain* or something
similar less subjective.
- gpiod_simple_event_handle_cb uses struct timespec.
This can create problems.
On 32 vs 64 bit platforms, because struct timespec is of different
size on 32 vs 64bit platforms, I think. (Looping in Arnd to verify.)
You might think "well it is either used on 32bit or on 64bit,
and everything else is compiled for that so what."
But in reality you have things like Python bindings, and those get
a *real* problem when things are in struct timespec, because they
map byte-by-byte and precompile code doing this map and
redistribute. Disaster.
With libmtp I often wish I has just used ISO 8601
https://en.wikipedia.org/wiki/ISO_8601
even if it means creating a string on one side and parsing it on
the other, because it is unambigous.
This might be an especially bad idea of mine but think it over.
Yours,
Linus Walleij
next prev parent reply other threads:[~2018-01-21 15:49 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 [this message]
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
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=CACRpkdb9JRsL1UFZ0+ipPmhYjd01Gy8+dL7yQ2RTkHJJdhf20w@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--cc=brgl@bgdev.pl \
--cc=clemens.gruber@pqgruber.com \
--cc=lars@metafoo.de \
--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).