summaryrefslogtreecommitdiff
path: root/bootstrap
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2023-05-09 11:43:22 -0700
committerVito Caputo <vcaputo@pengaru.com>2023-05-11 15:18:34 -0700
commit31a0147a720f2f0ef30df41512f41f43734662dd (patch)
treec381b2905eaf5cde93b83b2ee93adc148400b488 /bootstrap
parent1a8abe80dabd6b723897fc507808db30b126b3a4 (diff)
til_settings: introduce til_setting_spec_t concept vs. desc
For recursive settings the individual setting being described needs to get added to a potentially different settings instance than the one being operated on at the top of the current setup_func phase. The settings instance being passed around for a setup_func to operate on is constified, mainly to try ensure modules don't start directly mucking with the settings. They're supposed to just describe what they want next and iterate back and forth, with the front-end creating the settings from the returned descs however is appropriate, eventually building up the settings to completion. But since it's the setup_func that decides which settings instance is appropriate for containing the setting.. at some point it must associate a settings instance with the desc it's producing, one that is going to be necessarily written to. So here I'm just turning the existing til_setting_desc_t to a "spec", unchanged. And introducing a new til_setting_desc_t embedding the spec, accompanied by a non-const til_settings_t* "container". Now what setup_funcs use to express settings are a spec, otherwise identically to before. Instead of cloning a desc to allocate it for returning to the front-end, the desc is created from a spec with the target settings instance passed in. This turns the desc step where we take a constified settings instance and cast it into a non-const a more formal act of going from spec->desc, binding the spec to a specific settings instance. It will also serve to isolate that hacky cast to a til_settings function, and all the accessors of til_setting_desc_t needing to operate on the containing settings instance can just do so. As of this commit, the container pointer is just sitting in the desc_t but isn't being made use of or even assigned yet. This is just to minimize the amount of churn happening in this otherwise mostly mechanical and sprawling commit. There's also been some small changes surrounding the desc generators and plumbing of the settings instance where there previously wasn't any. It's unclear to me if desc generators will stay desc generators or turn into spec generators. For now those are mostly just used by the drm_fb stuff anyways, modules haven't made use of them, so they can stay a little crufty harmlessly for now.
Diffstat (limited to 'bootstrap')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved