Add support for a configuration file#326
Conversation
|
Should we keep the kernel configuration as is, and use it as defaults if the config doesn't specify? In lieu of removing those options? |
|
Also, shouldnt we load the config first? This would allow the kernel/ramdisk filenames to be set via config if desired (which i personally do desire.) IE:
We dont need to add the kernel/ramdisk settings now. My goal in these statements is to avoid a breaking api change when we want to add them, and preserve existing behavior. We can probably even get away with loading the config after, so long as we keep kernel defaults and make the file optional (if it isn't already). We would then be able to refactor the config file as described above, while sticking to a minor semver bump (where as current seems major to be, since it's a breaking change) |
We definitely need to keep the frame buffer config in the kernel options for semver compatibility. However, we could mark it as deprecated. Removing the log-related config options is fine because they're not released yet.
We can do that, but I don't think that we need to do it in this PR. Loading it earlier shouldn't be a breaking change.
I'm not sure if we should make all kernel config options overwritable. The kernel might rely on the config values, e.g. the specific address of a mapping or a minimum stack size. It's probably not a good idea to allow changing these values after compilation. |
phil-opp
left a comment
There was a problem hiding this comment.
Thanks a lot for the updates! Looks very good now.
phil-opp
left a comment
There was a problem hiding this comment.
Thanks for the quick updates!
|
Thanks a lot! |
Hello,
This PR adds support for de-serializing a JSON configuration file (
config.json). I chose JSON because is the only implementation that works in no-std.Thanks!