Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better config management #21

Closed
kristiankielhofner opened this issue May 10, 2023 · 5 comments
Closed

Better config management #21

kristiankielhofner opened this issue May 10, 2023 · 5 comments
Labels
dynamic configuration Config and behavior changes for post-dynamic configuration support

Comments

@kristiankielhofner
Copy link
Contributor

kristiankielhofner commented May 10, 2023

Instead of depending on using one gigantic sdkconfig.willow we should probably have at least three:

  • Defaults for everything (from espressif)
  • Overrides for Willow configs
  • Use overrides for things like the Willow Configuration options
@stintel
Copy link
Collaborator

stintel commented May 10, 2023

https://docs.espressif.com/projects/esp-idf/en/v4.4.4/esp32s3/api-reference/kconfig.html#using-sdkconfig-defaults
https://docs.espressif.com/projects/esp-idf/en/v4.4.4/esp32s3/api-guides/build-system.html#custom-sdkconfig-defaults
Have a look at SDKCONFIG_* in the 2nd link. We might be able to set things in a cmake, header or json file.

There is an option to generate this sdkconfig.defaults automatically but it's only in ESP-IDF v5: idf.py save-defconfig

@mineshaftgap
Copy link
Contributor

mineshaftgap commented May 16, 2023

Curious why not a web UI configuration like other ESP8266/32 projects where you connect to an open WiFi network to enter actual WiFi details and then after that you can change all the other configuration. With this approach a firmware can be distributed for those who are much less technically inclined. Obviously if providing a binary firmware, a checksum should be provided as well.

@kristiankielhofner
Copy link
Contributor Author

This issue is intended to track the configuration of the build system. No matter where a firmware image comes from, or how it's configured by the end user, it needs to be built by a build system somewhere.

We are evaluating a variety of approaches for easier end-user onboarding and configuration such as those mentioned on the wiki.

We have a larger issue than a firmware image and checksum. All a checksum assures is that it wasn't modified from the time we built and when the checksum was generated. It in no way assures the user that we didn't modify the code to stream their audio to some server we host (or who knows what), build it, generate a checksum, and hand them a binary.

The ideal approach is to use reproducible builds which we are also investigating given our focus on user privacy as a voice assistant.

We take our responsibility of powering a device with microphones present in the private lives of our users very, very seriously. We understand our primary differentiator is the trust of our users. For issues such as these we are going to approach them very methodically, deliberately, and with the involvement and feedback of the community and user base.

@mineshaftgap
Copy link
Contributor

Oh apologies, I didn't realize the intention for this.

@kristiankielhofner kristiankielhofner added the dynamic configuration Config and behavior changes for post-dynamic configuration support label Jun 16, 2023
@stintel
Copy link
Collaborator

stintel commented Sep 5, 2023

stintel added a commit that referenced this issue Sep 5, 2023
Use sdkconfig.defaults instead of maintaining a full sdkconfig in git.
The sdkconfig resulting from running `./utils.sh install` with this
commit should be the same as before this commit.

We can re-evaluate some of these values at a later stage, but we should
first start with identical sdkconfig. This will make bisecting easier.
If we were to change sdkconfig values in this commit, reverting the
commit would completely revert the use of sdkconfig.defaults.

Fixes: #21
stintel added a commit that referenced this issue Sep 11, 2023
Use sdkconfig.defaults instead of maintaining a full sdkconfig in git.
The sdkconfig resulting from running `./utils.sh install` with this
commit should be the same as before this commit.

We can re-evaluate some of these values at a later stage, but we should
first start with identical sdkconfig. This will make bisecting easier.
If we were to change sdkconfig values in this commit, reverting the
commit would completely revert the use of sdkconfig.defaults.

Fixes: #21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dynamic configuration Config and behavior changes for post-dynamic configuration support
Projects
None yet
Development

No branches or pull requests

3 participants