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