Re: [PATCH V7 3/8] libgpiod: Add rust wrapper crate

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Mon, Oct 31, 2022 at 1:34 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Thu, Oct 27, 2022 at 02:09:31PM +0200, Bartosz Golaszewski wrote:
> > On Fri, Oct 21, 2022 at 2:39 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > >
> > > On Fri, Oct 21, 2022 at 04:52:38PM +0530, Viresh Kumar wrote:
> > > > Hi Kent,
> > > >
> > > > >
> > > > > What if the Rust bindings version differ from the libgpiod version?
> > > >
> > > > Hmm, not sure which version should we return here. I think it should
> > > > just be libgpiod's version. Though I am fine with whatever you and
> > > > Bartosz decide.
> > > >
> > >
> > > You need both - separately.
> > >
> >
> > For C++ and Python, the API version stays consistent across all three
> > trees for simplicity. There are separate ABI numbers for libgpiod,
> > libgpiodcxx and libgpiosim. Rust doesn't seem to have this kind of
> > differentiation between ABI and API so I'd say we should have a single
> > API version but see below about the idea for the contrib/ directory.
> >
>
> My thinking was that if the Rust bindings end up being compiled into the
> app then it may be difficult to identify the version it was built with,
> as opposed to the version of libgpiod it is running against.
> Not sure you can always determine that from the Cargo.toml or
> Cargo.lock, or that those will always be available after the fact.
>
> Not a biggy if the two always remain compatible, but if a libgpiod change
> inadvertently triggers some fault in the Rust bindings then it could be a
> PITA just to determine the versions involved.
>
> > > > Will it be possible to get on with the current implementation and once
> > > > this is merged you send patches on top of it which can then get
> > > > reviewed properly by others too, who know Rust better than me ?
> > > >
> > >
> > > The Rust bindings are your baby, and I don't have any plans to be
> > > patching it.  And Bart is the arbiter of what gets merged, so that
> > > decision is his.
> > >
> >
> > I was thinking about it lately and figured that - since I don't know
> > Rust very well and cannot reliably maintain that part myself - how
> > about we create a 'contrib' directory in the libgpiod tree for this
> > kind of "third-party" bindings? The requirements for stability and
> > correctness in there would be more relaxed compared to the main tree?
> >
>
> The problem there is you thinking that you need to be able to personally
> support every line of libgpiod, and that it is not a team effort.
>
> Wrt the Rust bindings, I was assuming that either Viresh would provide
> support, or as his work appears to be on behalf of Linaro that they
> would have an interest in maintaining it.
>
> Similarly, I was assuming that I would be providing support for the
> proposed tool changes, should they ever get merged.  Though, based on the
> little feedback to date, I'm dubious about that ever happening.

Hey, this is literally the next item on my TODO list. I've just merged
the v2 API into master and am getting ready to dive head-first into
your patches.

Bart

> I could always split them off into a separate project, but maintaining
> an autoconf based setup doesn't interest me, particularly when the Go and
> Rust alternatives are one-liners that just work, so probably not.
>
> I was thinking that some forum for libgpiod, or more broadly GPIO
> user space development, would help increase community involvement,
> in both directions, and that might help address the Bartosz doesn't
> scale problem. But I don't have anything useful to add on that.
> The only relevant experience I have is with github, and while it would
> probably suffice I would explore other options first, with gitlab
> being the most obvious alternative.  No help there, I know.
>
> Sorry for not replying sooner.  I was hoping to do a respin in a more
> positive light, but that has eluded me and time marches on.
>
> Cheers,
> Kent.