Add support for a configuration file

[asensio-project]

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.

• Add a configuration file
• Make it fault tolerant
• Write the tests
• Write/Improve docs

Thanks!

[jasoncouture]

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?

[jasoncouture]

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:

• Set config to defaults.
• If (config_present) load
• for settings that are not set, do not set them leave defaults in place.
• Load kernel, read kernel config.
• For each setting not present in config file, apply kernel defaults.
• load ramdisk
• Continue as normal from this point.

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)

[phil-opp]

Thanks a lot!

[phil-opp]

@jasoncouture

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?

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.

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.)

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.

IE:

• Set config to defaults.
• If (config_present) load
• for settings that are not set, do not set them leave defaults in place.
• Load kernel, read kernel config.
• For each setting not present in config file, apply kernel defaults.
• load ramdisk
• Continue as normal from this point.

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]

Thanks a lot for the updates! Looks very good now.

[phil-opp]

Thanks for the quick updates!

[phil-opp]

Thanks a lot!