On Thu, Nov 3, 2022 at 1:38 AM Kent Gibson warthog618@gmail.com 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@gmail.com 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@linaro.org 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.