VMA 2020 05 minutes
Date: May 13th, 15:30 (CEST, UTC +2) Moderator: Kaspar
- Marian
- Cenk
- Leandro
- Oleg
- Kaspar
- Thomas
- Matthias
- Martine
- Francisco
- Ken
- Vincent
- Dylad
- Koen
- Kevin
- Alexandre
- Emmanuel
- Robert
- Michel
- Peter
- Alex
- Benpicco
- José
-
Debrief 2020.04 release (Leandro - 10m)
-
A quick word from 2020.07 release manager - 2min
-
Determining the Release Manager 2020.10
-
Organization and moderation of the next VMA
-
Kconfig (Leandro, 15min)
"The idea is to briefly go over what was exposed last time by José, talk about the current state and present some examples, so we can discuss based on that."
- CI (Kaspar, 15min)
"I'd also like to talk a bit about the current CI setup, to get a picture what people think about Murdock nowadays and whether people are more or less happy or we should consider looking for alternatives."
-
scapy_unroot (Martine, 5min) https://github.com/scapy-unroot/scapy_unroot
-
discourse? (Koen, 10min)
see slides from Leandro: https://riot-os.org/files/RIOT_VMA_2020_05___Debrief_release_2020_04.pdf
Focus on test automation
ideal target have nightlies running the release tests
Alex: how to handle interop tests -- multiple devices?
Martine: lets start somewhere... something is better than nothing
Emmanuel asks for volunteers, Koen volunteers (enthusiastically)
Emmanuel volunteers for VMA 2020.08
Martine volunteers to for the VMA 2020.11
see slides from Leandro: https://riot-os.org/files/RIOT_VMA_2020_05___Kconfig_dependencies.pdf Presentation by Leandro and Jose:
Currently can generate Kconfig file or historical cflags defaults
Describes Kconfig system
-- symbol dependencies, visible and invisible
New work -- feature modelling; just opened PR for this
Also module modeling
Describes the workflow for using Kconfig, to convert an existing makefile
Presentation includes examples -- by setting values in config file vs. menuconfig UI
Discussion about conventions fo the names of app.config entries -- CONFIG... vs. CONFIG_MOD...
Demonstration using gnrc networking example
Martine: (to slide 15) dependencies have to be selected "by hand" (bottom up)
Kaspar: menuconfig has to be used to configure a board
Jose: minimal configuration is not specific to a board
Kaspar: How to deal with a sensor driver that supports I2C and SPI?
Leandro: Set 'reasonable' default. If only one bus is present, use that. If both are present, it can be configured in the board config file
Emmanuel: what are the long-term perspectives using Kconfig?
Leandro: specifying module dependencies in a normalized way; beginner-friendly interface/documentation due to tools such as menuconfig;
Kaspar: at what point do we need to decide if we indeed model our dependencies with Kconfig?
José: like now-ish
Leandro: Do people like what they see? Any questions? Can others help development?
Oleg: List of disadvantages? Have they been resolved? Decision is between what alternatives? A non-readable way for dependencies vs using Kconfig? Seems like a no-brainer, but is the choice we have properly expressed as such?
Leandro: Changes use model, performance with Makefile is faster in some cases. Ideas to improve Kconfig -- remove filters. To run dependencies with menuconfig will not be faster; must spawn python and output files.
Kaspar: Experience with OpenWRT -- messy to work with config files; must edit files by hand. Our build system has issues with module dependencies. Kconfig for dependency moduling? Means we can't use build system with dependency tree.
Leandro: Export kconfig file? Serialize as build system requires.
Oleg: Kconfig used with other build systems, besides make?
Kaspar: Zephyr uses cmake with kconfig
Oleg: Performance -- any way to do dependency resolution in advance? Can it be cached?
Kaspar: Resolution is what takes time.
Benpicco: Can we determine which modules have changed?
Leandro: kconfig does not know which c files belong to a module (mapping file to module)
Martine: Build system knows kconfig info. We had something like this with Travis, but went aways from it.
Kaspar: ccache figuring out which have changed cancelled speedup
Leandro: ... a way to avoid running kconfig
Jose: workflow change -- are people ok with it?
Oleg: For people who know build system will take time. FOr newcomers, it seems to be a great improvement.
Koen: Dependency concerns -- order of selection.
Kevin: If lots of dependencies, can I see them? I want gnrc_networking, what are my options?
Jose: Guess a features provider. If you don't play with defaults, ... Must know what you need to enable.
Cenk : Kconfig is self describing. Can we group configurations?
Koen: Is this approach intuitive enough, especially for newcomers -- will not know what they want.
Cenk: Problem now trying to figure out which module to enable.
Koen: Sceptical about ordering of dependencies -- intuitive enough?
Martine: Example was easy. WHen dependencies get complex, that becomes less intuitive.
Jose: We need documentation anyway. You can always trace the modules with kconfig(?). Harder to do now. Example: random module; submodules difficult now. Easier to setup random with kconfig -- discoverability
Martine: Seleting sock_udp -- has mutliple optional dependcies. Can this be modeled in kconfig?
Jose: Yes, have done this before. Assuming want to know use a particular optional dependency, like open thread, ...
Martine: Will a total newcomer understand they must pick a specific option.
Leandro: Use feature concept for this? Need some implementer of API.
Jose: Must have one of the options in order to make the generic selection. Need documentation . Key is knowing the dependent modules. Zephyr example, didn't know internals, but was able to figure it out. Provides good visibility.
Kaspar: Can we reach concensus?
Kevin : Think about build system as it is. Does everyone agree we need to improve dependency and module configuration?
Consensus: yes
Kevin: Since kconfig is documented, can export the work. Majority of work is the modeling. Even if we decide not to use kconfig in the future, we still can export kconfig.
Kaspar: Exporting OK, but if complex, the export is not a panacea. Probably better than manual extrace from Make, but Kconfig export may not be good enough.
Jose: Kconfig -- provides symbols, a graph. Not specific to Kconfig?
Marian: Currently, dependencies enforced by default. Kconfig gives us freedom to pick what we want. Kconfig is not the only way, but the way we model dependencies now is not clear.
Cenk: Currently we have pseudomodules. kconfig can get rid of pseudo modules.
Martine: Kconfig -- just boolean configuration values. There will
Marian: Hidden defaults -- a solution should not have this.
Kaspar: Migration path: If Kconfig is a good idea, what are next steps:
Leandro: Martine suggests, for dependency and modeling in kconfig -- create feature branch to stay in sync with master.
Martine: Modeling should be done in feature branch. Actual reaolution of dependencies should be done after merge to master
Leandro: Basic switch just a couple of lines. Maybe feature branch for model and test and build with kconfig. When bring to master, we can switch after tests are done.
Martine: out of time; push to mailing list
Ben: the current approach has reached its limits; configuration via Kconfig might be cumbersome in some cases, but is still worth a try
Francisco: seems like a usable solution for now (we can reconsider in 3 years for now), vastly improving our current limitations of build system
Marian: do we have any alternative approaches? Or is the choice only between Kconfig or nothing (stay with what we have)
Kaspar: no.
Emmanuel: do we have consensus?
Oleg, Martine: yes, seems so.
=> consensus on migrating & proceeding with modeling dependencies in Kconfig
DO check out the PR though!
https://github.com/RIOT-OS/RIOT/pull/14055
Topic skipped due to lack of time.
Kaspar will take it to the mailing list.
https://github.com/scapy-unroot/scapy_unroot Martine: approach based on deamon + wrapping around a traditional socket which can communicate without root permissions
Topic skipped due to lack of time.
Koen will take it to the mailing list.