Re: Some changes to autoconfiguration APIs

[David Brownlee <abs%absd.org@localhost>]

On Sun, 1 Aug 2021 at 22:47, Jason Thorpe <thorpej%me.com@localhost> wrote:
>
> > On Aug 1, 2021, at 1:56 PM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
> >
> >>>      config_found(CF_VERSION, self, whatever, (const struct cfargs *){
> >>>          .search = ...,
> >>>          .locators = ...,
> >>>      })
> >
> >> What do you propose should be the behavior if the versions don't match?  I h$
> >
> > I thought the mail you replied to said, though admittedly partly by
> > implication:
> >
> >>> config_found() needs to check passed cf_version and convert for old
> >>> versions.  We are still left with a long tail of conversion code in
> >>> config_found(), but callers Just Work.
>
> Right, "callers Just Work" is carrying a lot of water here.  I want to know specifically how people think it should behave.  For example: What should happen in the case of a semantic conflict that can't be resolved during conversion?
>
> (If you can't tell, I'm a bit annoyed about folks having plenty of energy to express their distaste with one solution, only to float a hand-wavy alternative lacking specifics that also has flaws; sorry, abs@, I'm not trying to pick on you here...).

Not at all - my goal was to propose a potential alternative, and
poking at gaps helps evaluation :)

As I see it:

1) netbsd-9 had an API which provided some degree of type safety, but
was the result of accreting a baroque combinations of functions and
parameters to the point where it was difficult to use correctly - and
the tree had any number of examples which were actively wrong, and
would fail at runtime, mostly with misbehaviour, but potentially with
panics

2) current has an API which is much easier to understand and use, had
a nice degree of forward compatibility, though introduces some
potential misuse cases which can only be detected at runtime - as a
deliberate tradeoff to achieve a simple, compat calling API given the
limitations of C

3) This email takes one of Taylor's suggestions and hangs an explicit
version on the calls, which should give reasonable forward
compatibility (not as good as 2, but better than 1), keeps his
improved type safety, to hopefully give a more limited set of cases
which would fail at runtime (mis-specified cfargs contents, and cases
where a valid cfargs_v1 cannot be converted into a current cfargs)

Focussing on 2 & 3, the runtime issues are

a) Tag params missing value params & similar (applicable to 2)
b) Semantically valid options which do not make sense (applicable to 2 & 3)
For both of these the kernel can panic, or fail the attach with a
nasty loud message (which I rather prefer), but we have the same
runtime issue to handle for both 2 & 3

c) Parameters which made sense for an earlier version of the kernel
API, but do not now (applicable to 2 & 3)
The obvious reply is "Don't do that", but if for some reason we have
to, option 3 potentially has an advantage here, as for example the
conversion code called by config_found() can know that the "search"
value in cfargs_v1 needs to be swizzled differently to that of
cfargs_v2

tl;dr - all options allow code to call into config with bad data,
which it has to handle (panic or log & fail attach), we can only try
to reduce, not eliminate that.

(Let me know if I've reduced the hand waving in the right area :)

David