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