Re: [libgpiod][RFC v2] core: implement v2.0 API

[Kent Gibson <warthog618@gmail.com>]

On Sat, May 29, 2021 at 08:19:32PM +0200, Bartosz Golaszewski wrote:
> On Sat, May 29, 2021 at 1:23 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> 

[snip]

I meant to reply to this section as well but managed to snip it out...

> > > > the gpiod_chip_request_lines() or gpiod_line_request_reconfigure_lines()
> > > > is called it isn't too complex and so can be translated to the uAPI.
> > > > The check has to be performed as part of those functions either way, and
> > > > validating a transitional config doesn't prove anything.
> > > >
> > >
> > > Indeed. OTOH with return values in mutators taking integer values we
> > > would throw errors on invalid values passed. I need to think about it
> > > some more.
> > >
> >
> > I was assuming separate mutators for each of the enum values, as you do
> > for the active level but, with the offset and subset variants
> > multiplying the number of mutators, I can see why you would go with the
> > parameterized versions.  While you could still perform the range
> > checking as part of the translation to uAPI, that can more difficult for
> > the user to debug - depending on how many mutators they have applied.
> >
> > It is a trade-off, but I still lean towards the error-less mutators as
> > it simplifies user code - consolidating the error checking into one
> > place. A parameter being out of range means the user is doing something
> > stupid, or running a future app against an old libgpiod, in which case
> > they should be fine with slightly tougher debugging.
> >
> 
> Having error-less mutators here would mean something like a hundred
> functions just for setting the line config. I think that even with
> mutators taking enums we already have enough symbols. Let's keep them.
> 

We don't want separate mutators for each enum value as that would
explode the symbol space.  Agreed.

To be clear, in my "trade-off" paragraph above I was referring to your
existing parameterised error-less mutators, not the parameter-less
error-less mutators that I had been assuming.
Different paragraph and different things.

So, to conclude, I would lean towards keeping your existing mutators that
don't return error codes, rather than adding error codes.
And only performing the validation when the config is translated to uAPI,
not providing some functions to perform interim validation.
i.e. wrt error handling I'm fine with the mutators as they are.

OK?

Cheers,
Kent.