RFC: Discussion around describing driver/file metadata

[galak]

There are a number of cases in which we need metadata associated with files in the Zephyr source tree. This data needs to be "machine" parseable to build various tools, build systems, etc around.

This issue is to capture discussion around the topic, of both needs and how to implement such a metadata system.

[galak]

[REQ] For multi-API support for a single device we need to be able to know what APIs are associated with what device (and what DT compatible).

See #49374

[galak]

Some possible solutions for metadata tracking:

• Devicetree
• Kconfig
• CMake
• YAML
• source code

[mbolivar-nordic]

Assuming "[REQ]" means "requirement":

[REQ] For tracking people responsible for individual drivers, we need to be able to know what source code files are considered part of what drivers. Note that drivers files like adc_common.c and clock_stm32_ll_common.c complicate the situation somewhat.

[REQ] For usability and documentation, we need to know the devicetree compatibles that are handled by each driver (e.g. bosch,bme280 is handled by the bme280 sensor driver)

[REQ] For usability and documentation, we need to know the Kconfig symbols that are associated with each driver (e.g. BME280_MODE_NORMAL is associated with the bme280 sensor driver)

[galak]

Assuming "[REQ]" means "requirement":

yeah, was just trying to hopefully make it a little easier to separate requirements from discussion on proposed ideas/solutions.

[REQ] For tracking people responsible for individual drivers, we need to be able to know what source code files are considered part of what drivers. Note that drivers files like adc_common.c and clock_stm32_ll_common.c complicate the situation somewhat.

[REQ] For usability and documentation, we need to know the devicetree compatibles that are handled by each driver (e.g. bosch,bme280 is handled by the bme280 sensor driver)

[REQ] For usability and documentation, we need to know the Kconfig symbols that are associated with each driver (e.g. BME280_MODE_NORMAL is associated with the bme280 sensor driver)

Can you expand on this. I can see the need/value for associating "top-level" Kconfig symbol for a driver, what's the usecase for having awareness of the driver specific features like (BME280_MODE_NORMAL)?

[nashif]

same topic #38725 (comment)

[mbolivar-nordic]

Can you expand on this. I can see the need/value for associating "top-level" Kconfig symbol for a driver, what's the usecase for having awareness of the driver specific features like (BME280_MODE_NORMAL)?

Consider the alternatives:

1. "just grep the source code for config.TOP_LEVEL_SYMBOL and figure it out for yourself"
2. "just dig around in menuconfig and figure it out for yourself"

These are what Linux provides. I think they are self evidently pretty gross from a user perspective, but maybe I'm alone in that. I think programming interfaces should be able to have documentation that explains how to use them that doesn't require people to RTFS.

[bjarki-andreasen]

The properties files and associated scripts have been isolated and moved to this PR #50441