Re: Some changes to autoconfiguration APIs

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sun, 1 Aug 2021 14:47:39 -0700
> From: Jason Thorpe <thorpej%me.com@localhost>
> 
> >>> 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?

We could use __RENAME("config_found_v123") to make it a linker error
if there's a semantic conflict that can't be resolved dynamically by
the implementation of config_found.  We could even make config_found a
macro so that it automagically passes a minor version for semantic
changes that can be handled, without adding extra verbiage to all the
callers:

#define config_found(x,y,z)	_config_found(CF_MINOR_VERSION,x,y,z)
device_t _config_found(int,foo,bar,baz) __RENAME("_config_found_v123");

But, can we go back to what problem this is trying to solve in the
first place?  What extensions to config_found have happened or are
planned to happen so frequently that losing all type safety in the API
is worth not bumping the kernel version number once in a while?

(As an aside: We really need to change the API at a deeper level
anyway so that config_found returns some kind of weak pointer to a
device, since the current model of device_t just fundamentally doesn't
work with concurrent detach...)