RIOT icon indicating copy to clipboard operation
RIOT copied to clipboard

docs/kconfig: Add design patterns for kconfig

Open MrKevinWeiss opened this issue 2 years ago • 7 comments

Contribution description

  • Adds some rule of thumb statements with some reasoning why
  • Adds a number of generic examples as well as read examples of design patterns used for kconfig.

Testing procedure

Issues/PRs references

MrKevinWeiss avatar Jan 24 '22 13:01 MrKevinWeiss

TODO

  • Add patterns for multiple backends
  • Add more real examples
  • Review and come up with pattern for stdio dependency modelling
  • Say something about select is now preferred, opposed to linux and zephyr, so that applications will not require different configs for each hardware configuration
  • circular dependencies

MrKevinWeiss avatar Jan 25 '22 10:01 MrKevinWeiss

It seems pretty unpleasant to link separate kconfig files from the docs... My current solution will be adding a commit after everything is rebased and squashed to point to the commit hashes of the linked kconfig files. This must happen at the end though.

MrKevinWeiss avatar Jan 26 '22 11:01 MrKevinWeiss

oops

MrKevinWeiss avatar Jan 26 '22 11:01 MrKevinWeiss

Note, if there are no configurable options for a driver level module then it can be config not menuconfig as to not confuse a kconfig user into thinking there may be more options available.

MrKevinWeiss avatar Feb 01 '22 12:02 MrKevinWeiss

TODO:

Add something about board specific configs and overriding configs. Adding hardcoded modules to a $(BOARD).config and modules that require dependencies to the board Kconfig with an overriding config (or choice), keeping in mind that the depends on * must be duplicated for the config only.

MrKevinWeiss avatar Feb 04 '22 07:02 MrKevinWeiss

Now that all the boards are in, it would be good to settle on this.

Before the big push in the networking I would like this, and an update based on this (possibly some treewide updates).

MrKevinWeiss avatar Feb 11 '22 10:02 MrKevinWeiss

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

stale[bot] avatar Sep 21 '22 05:09 stale[bot]

What's the current state of this documentation? Is this ready to be reviewed? I cloud do a try to understand what you're describing and point out what's unclear to me review.

jue89 avatar Oct 27 '22 10:10 jue89

Hmmm, I have something of a chicken and egg problem with the current state, I want the links to work but they won't until it is in.

Let me have another go at it (once I am done trying to fix the nightlies). I will ping you sometime next week when I will be ready... That is unfortunately the speed that I work.

MrKevinWeiss avatar Oct 27 '22 11:10 MrKevinWeiss

Oh don't worry - I really don't want to put any pressure onto you. Take the time you need.

I'm just keen to get Kconfig in - doing all the dependency modeling twice for every bit you add or change is good advertisement to move to only one dependency system ... and I'd say Kconfig is the better choice here.

jue89 avatar Oct 27 '22 12:10 jue89