I really like that idea! I am not super familiar with the layering of Kconfig feature options, but I am of the understanding that a board Kconfig file might not list itself all the features it has. So the parser would have to determine which chip the board is using, and by extension which features that chip supports, etc.
Also, I noticed that some boards might have a chip which implements some feature (like Bluetooth/WiFi) but doesn't actually include the initialization of that feature in its bring-up code. It would be incorrect to give it the feature tag if it doesn't implement the bring-up code for it. I suppose using Kconfig to generate feature tags would be helpful for doing it en masse, but I almost wonder if adding them by hand to the documentation wouldn't be easier. On one hand, contributors might forget to update the feature tags after adding a feature, but on the other hand significant effort must go into maintaining a parser and avoiding the possibility of advertising a feature that isn't implemented. But yes, I think this would be massively helpful for creating NuttX based products. At least in my use cases, sometimes it's nice to filter by "has FPU, has SDMMC, has WiFi", etc. It would be useful to narrow down chip selections based on what NuttX has support for. -- Matteo Golin
signature.asc
Description: PGP signature