Re: [libgpiod v2][PATCH 1/4] tools: line name focussed rework

[Kent Gibson <warthog618@xxxxxxxxx>]

On Thu, Jul 07, 2022 at 11:01:49AM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 7, 2022 at 4:24 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > On Wed, Jul 06, 2022 at 10:20:00PM +0200, Bartosz Golaszewski wrote:
> > > On Mon, Jun 27, 2022 at 3:46 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > >
> > > > Rework the tool suite to support identifying lines by name and to
> > > > support operating on the GPIO lines available to the user at once, rather
> > > > than on one particular GPIO chip.
> > > >
> > > > All tools, other than gpiodetect, now provide the name to (chip,offset)
> > > > mapping that was previously only performed by gpiofind. As names are not
> > > > guaranteed to be unique, a --strict option is provided for all tools to
> > > > either abort the operation or report all lines with the matching name, as
> > > > appropriate.
> > > > By default the tools operate on the first line found with a matching name.
> > > >
> > > > Selection of line by (chip,offset) is still supported with a --chip
> > > > option, though it restricts the scope of the operation to an individual
> > > > chip.  When the --chip option is specified, the lines are assumed to be
> > > > identified by offset where they parse as an integer, else by name.
> > > > To cater for the unusual case where a line name parses as an integer,
> > > > but is different from the offset, the --by-name option forces the lines
> > > > to be identified by name.
> > > >
> > >
> > > We could potentially extend it by allowing multiple --chip arguments
> > > for multiple chips but let's not go there unless requested.
> > >
> >
> > We could but then we'd have to custom parse the command line.
> > Or repeatedly apply getopt()?
> > So yeah, keep it simple for now.
> 
> getopt() will go to the relevant switch case everytime it encounters
> the flag, then you can process it and add it to the list.
> 

Yeah, but the lines are positional parameters between the --chip
options.
i.e.
 
 --chip gpiochip1 1 2 4  --chip gpiochip3 6 7 8

I thought getopt() bails when it hits positional args?
Or am I missing something?

> >
> > > > The updated tools are intentionally NOT backwardly compatible with the
> > > > previous tools. Using old command lines with the updated tools will
> > > > almost certainly fail, though migrating old command lines is generally as
> > > > simple as adding a '-c' before the chip.
> > > >
> > > > In addition the individual tools are modified as follows:
> > > >
> > > > gpiodetect:
> > > >
> > > > Add the option to select individual chips.
> > > >
> > >
> > > We discussed at some point that gpiodetect should also check if any of
> > > the files it iterates over is a symbolic link to a GPIO device and
> > > print some info accordingly (e.g. foobar [link to /dev/gpiochip2])-
> > > are you thinking about adding this too?
> > >
> >
> > Did we?  My bad then - I clearly forgot and instead filtered the symlinks
> > out so it only reports actual chips (btw the v1 tools report the symlinks
> > by repeating the actual, which is the worst of both worlds).
> >
> 
> I think so. In any case I think this would be useful.
> 

gpiodetect on a symlink will report for the chip that link points to.
Similarly gpioinfo.
Isn't that sufficient?

i.e. the bare form of gpiodetect and gpioinfo report all the actual
chipts, while the specific form reports whatever the provided path,
resolves to, including following symlinks.

...
> > >
> > > readline is licensed under GPLv3 - this bleeds into gpioset and will
> > > make a lot of companies bounce off of it. Any chance you could use
> > > libedit instead? It's supposed to be a drop-in replacement for
> > > readline but I have never used it first hand.
> > >
> >
> > Hey, you mentioned readline before I implemented it.
> > Though I don't recall "avoid" being mentioned :-(.
> >
> 
> No, you're right, I mentioned it but then realized it's GPLv3.
> 
> > Ok, I'll take a look.  Hopefully it is just a drop-in.
> >
> > Out of curiosity which aspect of GPLv3 is the problem, for a tool
> > which is publicly available and they aren't going to modify?
> > Just having a GPLv3 library on their system?
> >
> 
> You'd be surprised how allergic companies are to GPLv3. Anything
> "tainted" with GPLv3 is often banned.
> 

Ok, news to me.  I might quarantine them to prevent building against
them, but banning them outright is a bit extreme.
OTOH I've worked at places that banned Linux (or tried to anyway).

Anyway, I'll look into the alternatives.

Cheers,
Kent.