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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 3, 2022 at 1:38 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Wed, Nov 02, 2022 at 05:34:20PM +0100, Bartosz Golaszewski wrote:
> > On Wed, Nov 2, 2022 at 2:08 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > >
> > > On Wed, Nov 02, 2022 at 01:47:44PM +0100, Bartosz Golaszewski wrote:
> > > > On Wed, Nov 2, 2022 at 5:00 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> > > > >
> > > > > On 31-10-22, 20:33, Kent Gibson wrote:
> > > > > > 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.
> > > > >
> > > > > I will surely help in maintaining the Rust part. Not an issue.
> > > > >
> > > >
> > > > Sounds like a plan. I'm going through Kent's gpio-tools patches and
> > > > rust bindings are next in line.
> > > >
> > >
> > > The rust bindings might make it in before they do - you may find that
> > > they are a bit more different from the old tools than you were expecting.
> > >
> >
> > Yeah, I can tell that. :)
> >
> > I have lots of non-functional minor things to point out - mostly
> > coding style etc. - that I will probably just fix locally when
> > applying.
> >
>
> Looks like there will be a v5 for the optional interactive set, if
> nothing else, so let me know and I can fix them as well.
>
> > One thing that stands out though is the dependency on libedit - do you
> > think we could make the gpioset interactive mode a configurable
> > feature with its own configure switch that could be left out if we
> > don't want to depend on any external libraries?
>
> Well, libedit was your preferred choice.

It's still is - it's not about the choice of the library but about
keeping it possible to build a set of command-line tools with no
dependencies other than libc.

> But, yeah, making the interactive mode optional is a good idea.
>
> Any preference on the name for the config flag?
> --enable-gpioset-interactive ?
>

Sounds great.

> One other major thing I had been considering, and implemented in my Rust
> version[1], is renaming the tools, since it isn't intuitively obvious,
> to me anyway, what gpiodetect, gpioinfo, gpiomon, and gpiowatch do.
>
> I went with:
>  gpiodetect -> gpiochip
>  gpioinfo   -> gpioline
>  gpiomon    -> gpioedges
>  gpiowatch  -> gpionotify
>
> where the names try to indicate the information returned, rather than
> how it is collected.
> And yeah, I got stuck with gpiowatch/gpionotify as I couldn't come up
> with a short meaningful name for line info changed events.
> Suggestions welcome.  And lice is not an option.
>
> gpioget and gpioset remain unchanged as they are already as clear as can
> be.
>
> Would that work for you, or would you prefer to stick with the existing
> names?

I don't know if it is because I'm used to the previous names but none
of the first three make much sense to me. I think it's better for the
names to indicate what the program is doing, not what it's returning.

On the other hand - gpionotify is great, go for it!

Bart

>
> Cheers,
> Kent.
>
> [1] https://crates.io/crates/gpiocdev-cli



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux