diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2023-08-05 00:07:16 -0700 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2023-08-05 00:17:33 -0700 |
commit | 3cc953518d1c2b84f08f5693d3566db4462623a8 (patch) | |
tree | 48f04a0f90bd465d822ec31900a631d88959e5f2 /m4 | |
parent | d7b92d1b6dd1b152c7263763de7e8f6b174583d4 (diff) |
til_setup,*: add til_setup_t.creator pointer
Particularly with nested modules it's annoying to have to stow
the module separate from the setup during the setup process.
If the baked setup included the module pointer in the
non-module-specific-setup part of the setup, then nested settings
could finalize using the generic module setup wrapper and just
rely on this til_setup_t.creator pointer to contain the
appropriate module. Which should enable tossing out a bunch of
copy-n-pasta surrounding nested modules setup.
Note this has to be a void* since til_setup_t is a generic thing
used equally by both the fb code and the module code. Hence why
this is called "creator" and not "module", as well as the void*
as opposed to til_module_t*.
Also if rototiller ever grows a sound backend, the setup
machinery will be reused there as well, and it'll be yet another
creator handle that isn't an til_fb_ops_t or a til_module_t.
It's assumed that the callers producing these setups won't be
trying to pass them to the wrong places i.e. a module setup
getting passed to an fb backend and vice versa.
I'm mildly annoyed about having to move the various til_module_t
blocks to above the module's foo_setup(), but it seemed like the
least annoying option. This may be revisited.
Diffstat (limited to 'm4')
0 files changed, 0 insertions, 0 deletions