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

Attachment: signature.asc
Description: PGP signature

Reply via email to