summaryrefslogtreecommitdiff
path: root/src/til_setup.h
AgeCommit message (Collapse)Author
2023-08-31til_setup: add another helper for setup_func baking failsVito Caputo
This introduces til_setup_free_with_ret_err() which just does the common idiom of: - free the setup - return with err code so all these failure cases can be reduced to just a direct return of calling this function. Simpler version of til_setup_free_with_failed_setting_ret_err(), which could have been reuesed for this by making the settings-related parameters optional... but this way the call sites are less verbose and these are tiny helpers it's harmless.
2023-08-30til_setup: add helper for setup_func baking failsVito Caputo
This introduces til_setup_free_with_failed_setting_ret_err() which just does the common idiom of: - free the setup - store the failed setting - return with err code so all these failure cases can be reduced to just a direct return of calling this function.
2023-08-05til_setup,*: add til_setup_t.creator pointerVito Caputo
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.
2023-05-30til_setup: hash til_setup_t.pathVito Caputo
Preparatory commit for deprecating til_module_context_t.path in favor of mandatory til_module_context_t.setup providing the settings-derived context path. Future commit will drop til_module_context_t.{path,path_hash}
2023-05-28til_setup,*: note settings path in til_setup_tVito Caputo
This commit adds passing the settings instance to til_setup_new() which is used for deriving a path for the setup via til_settings_print_path() on the supplied settings. That path gets an allocated copy left in the returned til_setup_t at til_setup_t.path This path will exist for the lifetime of the til_setup_t, to be freed along with the rest of the baked setup instance when the refcount reaches 0. The incoming til_settings_t is only read @ til_setup_new() in constructing the path, no reference is kept. Basically the til_settings_t* is just passed in for convenience reasons, since constructing the path needs memory and may fail, this approach lets the existing til_setup_new() call error handling also capture the path allocation failures as-is turning til_setup_new() into a bit more of a convenience helper. Note that now all code may assume a til_setup_t has a set and valid til_setup_t.path, which should be useful for context creates when a setup is available.
2023-05-11til_setup: refcount til_setup_tVito Caputo
The whole point of til_setup_t is to represent the baked, most conveniently usable form of a setup derived from one or more settings instances. Things generally go from the serialization format "settings string" to til_settings_t eventually culminating in a til_setup_t. So the process of making a til_setup_t is rather tedious and kind of costly. Once into a til_setup_t it's desirable to just hang on to this form and reuse it if possible. The way a til_setup_t baked setup is put to use is in a read-only fashion where it basically just informs behavior, so it makes a lot of sense to enable refcounting the thing and letting whatever can make use of it bump the refcount and hold onto the pointer, accessing the contents whenever it needs to answer a question about that particular setup. The immediate impetus for this is actually rtv's snow_module setup. In rtv every channel switch may recreate the context, if the context has expired. In the case of the snow module, the context always expires, and we definitely want to discard the context while playing the next channel. But when the snow resumes, in order to recreate the context as configured, we need the same setup again. It just becomes clear that what's needed is a way to pin the snow_module's setup for this reuse to be safe. There's also plenty of other modules that have been piecemeal copying settings into their context, when what would really make more sense is to just ref it and stow the pointer, then unref on their context destroy. They can just access the setup via the pointer as needed, instead of having to duplicate the setup in their context. Indeed, some module contexts even embed the entire setup just to copy its contents over by value. In simple/small scenarios that's fine, and I'm sure in those particular cases it's perfectly safe to do. It just seems unnecessary altogether. Another small change made is supporting NULL free_func, which will default to libc's free(). Most til_setup_new() call sites are passing free() with an annoying cast, those can be changed to NULL.
2022-04-24til_setup: introduce til_setup_free()Vito Caputo
simple wrapper around til_setup_t.free()
2022-04-24til_setup: add til_setup_new() helperVito Caputo
For use when setup functions allocate their private setup to return in *res_setup. They specify the size of their private setup, and supply the free function to use. This may be libc's free() when it's a simple setup struct, or a bespoke free function when deep/complex freeing is required for cleanup. It's expected that callers will be embedding til_setup_t at the start of their private setup struct, and returning a pointer to this in *res_setup which would be the same value as a pointer to to their private setup struct.
2022-04-24til_setup: introduce til_setup_tVito Caputo
Preparatory commit for providing a res_setup type to replace void*. The impetus for this isn't just pursuit of less void*, but primarily implementing setup freeing by embedding this struct into the private setup types. An alternative method of adding setup freeing would have been to introduce something like til_module_t.free_setup(). But that would require having the til_module_t on hand, and the whole setup machinery is more generalized than til_module_t anyways. This way anything can simply embed the struct in their private setup instance and return the pointer to that in *res_setup. They should always be able to find their containing struct's offset from the til_setup_t* they returned. Either by using container_of(), or simply placing it at the start of the private setup struct.
© All Rights Reserved