[Tracking]: modeling dependencies in Kconfig

[fjmolinas]

Description

These issues want to keep track of MODULES/PKG/CPU/BOARDs that are not modeled in Kconfig. Things already modeled at the time of this issue are not included.

Help is very welcomed, if you are already tackling something don't hesitate to list your name or an opened PR next to the item list. Initial work in branches is also welcome, someone else can take over later, so don't hesitate to reference either.

no exhaustive-list please extend:

• [ ] cpu:

  • [ ] cortex-m:
  • [x] stm32
    • [x] nucleo
    • [x] others... https://github.com/RIOT-OS/RIOT/pull/17374
  • [x] nrf52 https://github.com/RIOT-OS/RIOT/pull/16837
  • [x] cc2538
  • [x] efm32 #16912
  • [x] cc26x0_cc13x0 #17236
  • [x] cc26x2_cc13x2 #17236
  • [x] cc26x_cc13xx #17236
  • [x] kinetis #17235
  • [x] lm4f120 (Not much required, board modelled in #17237)
  • [x] lpc1768 #17238
  • [x] nrf51 cpu/nrf51: model kconfig #17274
  • [x] nrf9160 https://github.com/RIOT-OS/RIOT/pull/17291
  • [x] qn908x #17277
  • [x] rpx0xx (nothing required)
  • [x] sam3 #17240 (related boards)
  • [x] samd21 #17355 (related boards)
  • [x] samd5x #17331
  • [x] same54 #17255
  • [x] saml1x (boards modelled in #17263)
  • [x] saml21 (boards modelled in #17270)
  • [x] native
  • [x] esp32 #17232
  • [x] esp8266 #17232
  • [x] avr #16929
  • [x] arm7
  • [x] lpc23xx #17279
  • [x] riscv #16909
  • [x] mips (OBSOLETE)
  • [x] msp430 https://github.com/RIOT-OS/RIOT/pull/17290

• [ ] pkgs:

  • [x] mynewt-core https://github.com/RIOT-OS/RIOT/pull/16780
  • [x] uwb-core https://github.com/RIOT-OS/RIOT/pull/16780
  • [x] uwb-dw1000 https://github.com/RIOT-OS/RIOT/pull/16780
  • [ ] ccn-lite
  • [x] cmsis-dsp #16912
  • [x] cmsis-nn #16912
  • [x] cryptoauthlib #18011
  • [ ] edhoc-c
  • [x] esp8266_sdk #17232
  • [ ] fatfs
  • [x] fido2_tests #17435
  • [x] flatbuffers #17908
  • [x] gecko_sdk #16912
  • [x] jerryscript #18012
  • [x] libbase58 #19623
  • [ ] littlefs
  • [ ] littlefs2
  • [x] lua #18017
  • [ ] lwext4
  • [ ] lwip
  • [x] micropython #19672
  • [ ] nimble
  • [x] openthread #19671
  • [ ] openwsn
  • [ ] paho-mqtt
  • [ ] semtech-loramac #18005
  • [ ] spiffs
  • [x] tflite-micro #17908
  • [ ] tinydtls
  • [ ] wakaama
  • [ ] wolfssl

• [ ] sys:

  • [ ] can #19675
  • [x] ecc #19636
  • [x] evtimer #19636
  • [ ] fuzzing
  • [ ] net
    • [ ] ieee802154 submac #16842
  • [x] newlib_syscalls_default #14626 and 9557a9dfc40990eee4199ab3e14643cfcef8326f
  • [x] picolibc_syscalls_default #16909 9557a9dfc40990eee4199ab3e14643cfcef8326f
  • [x] pipe #19636
  • [ ] puf_sram
  • [ ] riotboot
  • [x] shell_lock #19636
  • [ ] stdio:
  • [ ] stdio_nimble
  • [x] stdio_null #14904
  • [x] stdio_rtt #17299
  • [x] stdio_semihosting #19651
  • [x] stdio_uart #14904
  • [ ] stdio_udp
  • [ ] suit
  • [ ] universal_address
  • [x] usb: #19086
  • [ ] vfs: #19403
  • [ ] vfs_util

• [ ] drivers:

  • [x] at86rf2xx #17789
  • [x] at86rf215 #17789
  • [ ] atwinc15x0 #17382
  • [ ] cc1xxx_common
  • [ ] cc110x
  • [x] cc2420 #17789
  • [x] cst816s #17459
  • [x] dac_dds #17669
  • [x] dose #17739
  • [x] enc28j60 #17739
  • [x] encx24j600 #17739
  • [x] ethos #17739
  • [x] kw2xrf #17789
  • [x] kw41zrf #17789
  • [x] mrf24j40 #17789
  • [x] netdev #17739
  • [x] netdev_ieee802154_submac #17789
  • [x] nrf24l01p #19650
  • [ ] nrf24l01p_ng
  • [x] w5100 #17739
  • [ ] xbee

[fjmolinas]

Note AFAIK in sys most modules that are pending for modeling are related to networkin. Same goes for pkg and drivers

[fjmolinas]

@maribu any change you could take a look at avr? Do you seem to be doing a lot of work there?

[fjmolinas]

Since there is some discussion of eventually dropping MIPS it should be low priority.. (probably the same for MSP430)

[MrKevinWeiss]

Just to note that we would like to get all the cpus in for this release, this would allow us to stop testing select apps twice and use pure kconfig for dep resolution.

[MrKevinWeiss]

Just so it is written down somewhere. The configs we are using to set things for the STDIO_USB_ACM_CDC stuff I think will fail on apps that don't use stdio. They get hardcoded in by the .config file but they really should only be brought in if there is a MODULE_STDIO.

We will eventually have to address this (though maybe not now).

[Enoch247]

I wanted to make an offer to help out with kconfig. I'm pretty confident with Makefiles and kconfig's syntax. Any place in particular I should start?

[MrKevinWeiss]

Heck ya @Enoch247, if you didn't read the kconfig docs I would start with that.

Currently I am working on getting all boards (that are not deprecated) to run on some applications. There are still some boards that will not work on the approved applications list, but there are already PRs out there to fix it.

The next step would be to add more applications to the TEST_KCONFIG_TEST_ALLOWLIST, this will expose more modelling corner cases. Note that adding more applications will also increase the CI time so we didn't want to overdo it. Once we are confident that the modelling is correct with kconfig we can only build test with kconfig and skip the make dependency resolution, reducing the CI time.

Though I have been talking about it for a while, I also intend on documenting some design patterns that we want to use in kconfig, specifically targeting drivers that can be selected by "default" based modules such as SAUL_DEFAULT or TOUCH_DEV. There will be some work getting everything to the same standard once that comes in.

The final thing that is missing will be modelling the network dependencies, which will be pretty challenging as you need to understand the network stacks as well as kconfig. I image we will start working on that pretty soon. I know we all want to complete this migration, and it seems like things are picking up.

@leandrolanzieri @fjmolinas and I will be happy to answer any questions and provide help. The best thing you can do is document the questions and answers in a concise and add it to the docs. I know I have asked the same things from @leandrolanzieri several times already.

[Enoch247]

I finally had a chance to poke around on this. As a simple test, I tried make -C examples/saul menuconfig then played around with the shell's config symbols, then make all term. Everything worked as expected, so I don't really have any questions so far. I'm struggling to find any concrete task to sink my teeth into here. I noticed riotboot is on the checklist above and is an area I was tinkering with earlier today, so I could work on adding the appropriate Kconfig files for that if nothing else, unless you have something else you would prefer I start with.

When I do have questions, I figured I'd document them and the answers in a gist or something, then we can figure out how to put them into something more formal once I get a bit further into it. Unless you had something else in-mind.

[MrKevinWeiss]

I figured I'd document them and the answers in a gist or something

Perfect.

I have started a design patterns PR, we can probably add some things in there.

I haven't looked into riotboot, but keep in mind the networking is not yet modelled which may be a requirement for at least some of riotboot.

Other than that, good luck!

[aabadie]

I edited the issue with new items and marked the ones that are in progress or already done.

[benpicco]

As per the last VMA we decided to drop Kconfig, so this issue can now be closed.