From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>,
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: Tue, 23 Jan 2018 16:14:21 +0100 [thread overview]
Message-ID: <CAMRc=Mc2f7RAoYE3-0MbxUC=1eua0wYjGqd-R+PMwDzLXxcS3Q@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a1MSToyMTnqN1bVvzwK92CdDvAnJCZctbSgu8iM8t3KAQ@mail.gmail.com>
2018-01-22 12:12 GMT+01:00 Arnd Bergmann <arnd@arndb.de>:
> On Mon, Jan 22, 2018 at 12:02 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> 2018-01-22 10:25 GMT+01:00 Arnd Bergmann <arnd@arndb.de>:
>>>
>>> - on x86, the structures are incompatible between 32-bit and 64-bit
>>> user space, as the former has no padding.
>>
>> Is this really an issue? Do distros really ship the same bytecode for
>> 32 and 64 bit architecures? I have never run into such problems
>> despite having used different python bindings for C libraries (I'm not
>> sure however how many of them dealt with any visible C structs).
>
> It's a huge issue, yes. You should be able to run an 32-bit distro
> or just a standalone 32-bit binary with a 64-bit kernel. This driver
> is otherwise written carefully to allow that, and it will work on all
> other architectures AFAICT, just not on x86.
>
Besides using struct timespec, I have other structs in gpiod.h which
would pose problems for ctypes-based python bindings - for example
struct gpiod_line_request_config which contains a pointer (C string).
If instead of using ctypes, I'd just use python's C extension modules,
is there any other trap caused by different data layout between 32 and
64 bit architectures that I should be aware of?
Also: if python bindings are the only victim of that - I'm ok with
timespec. It's up to bindings to provide a correct interface after
all, isn't it?
Best regards,
Bartosz Golaszewski
next prev parent reply other threads:[~2018-01-23 15:14 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 [this message]
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='CAMRc=Mc2f7RAoYE3-0MbxUC=1eua0wYjGqd-R+PMwDzLXxcS3Q@mail.gmail.com' \
--to=brgl@bgdev.pl \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--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).