Application object tree

[mkschreder]

Is your enhancement proposal related to a problem? Please describe. When working with applications it is often convenient to use device tree as a way to instantiate and connect together multiple application components and services. However, doing this breaks the idea of device tree being used only for configuring hardware. When we do this, device tree becomes a mix of hardware configuration and application component configuration.

Currently zephyr supports zephyr,user node which allows user to add application specific properties, but this does not allow for easy capture of intercomponent dependencies. Dependencies are most easily handled by creating a custom binding and then linking the instances through phandles.

Describe the solution you'd like I would like to establish a concept of application object tree that mimics the device tree but is kept separate from hardware device tree. This object tree would be used to bootstrap application components.

The nodes would use a hierarchy of bindings just like device tree. This may allow certain features to be inherited by application components such as for example being able to have a "base" binding for a component that automatically creates and configures a thread with stack for that component based on some base property values and the user just needs to implement a component "main" function that then automatically runs in its own thread.

Describe alternatives you've considered Using the device tree as is and use device tree bindings for application code as well. Application components are modeled just like device drivers and device tree nodes are added to application overlays under "boards" folder of the application in order to instantiate them on different target platforms (don't like this idea though because it does not facilitate reuse. Is there a better way?)

[hongshui3000]

It reminds me of the sof audio topology, which seems to be somewhat similar to this idea.
https://www.alsa-project.org/main/index.php/ALSA_topology https://thesofproject.github.io/latest/developer_guides/topology2/topology2.html

[jukkar]

Sounds pretty similar what was proposed for network configuration data in https://github.com/zephyrproject-rtos/zephyr/issues/29750

[nordicjm]

Can you give an example of what the components you would want to use with such a system? It's not clear to me from the description of what exactly you want to do because things like subsystems can be enabled with use of Kconfigs and they can depend on, imply or select other Kconfigs to enable requirement/dependency tracking

[mkschreder]

@nordicjm do you see any pitfalls with using device tree for managing all application component dependencies? Ie. say you have a server application that is meant to expose sensor readings over can bus and over ble. Do you see any issues with making a device tree node for the server object and then linking it to sensor and can bus using phandles?

It seems wrong to me to mix application objects with hardware objects. However the concept of instantiation through device tree description makes a lot of sense.

[nordicjm]

@nordicjm do you see any pitfalls with using device tree for managing all application component dependencies? Ie. say you have a server application that is meant to expose sensor readings over can bus and over ble. Do you see any issues with making a device tree node for the server object and then linking it to sensor and can bus using phandles?

I don't see what the point of this is when this is already fully supported and working using Kconfig

[mkschreder]

@nordicjm do you see any pitfalls with using device tree for managing all application component dependencies? Ie. say you have a server application that is meant to expose sensor readings over can bus and over ble. Do you see any issues with making a device tree node for the server object and then linking it to sensor and can bus using phandles?

I don't see what the point of this is when this is already fully supported and working using Kconfig

Kconfig has no concept of instances. If you want to configure two instances you either have to share parameters for both or create kconfig parameters with suffixes for instances. Weird at best.

Device tree has excellent concept of instances but is meant for hardware configuration where mixing application object instantiation into it pollutes this concept of only using it for defining hardware structure.

There needs to be a way to configure application structure in the same way.

[nordicjm]

Your description was:

say you have a server application that is meant to expose sensor readings over can bus and over ble.

Here, CAN is singular, BLE is singular, there may be many sensors but that's completely application driven logic what you do with that sensor, when you read it, where you forward the readings to.

[kartben]

Maybe @petejohanson will want to chime in here

[carlescufi]

If the proposal in https://github.com/zephyrproject-rtos/zephyr/pull/68127 is generalized, then one could add a app: node in the .yml to achieve this without abusing Devicetree.

[petejohanson]

Maybe @petejohanson will want to chime in here

Since @kartben has outed our completely discouraged use of DTS, I can certainly chime in on the kinds of things we've leveraged DTS for in a non-standard way, to see which of those might inform this work. In particular, there's two main categories of things we're doing:

Consuming Devices With Different Application Config Per Device

• Configuration settings that set up handling for 1-N devices that each need different settings for how things are applied. Example from our upcoming pointer integration built on the new input subsystem: We need a way to have multiple pointers handled in the system, and per device post-processing of the events from those devices, e.g. XY axis swapping, value inversion, scaling. That doesn't describe the hardware, per-se, but is linked to the devices described in the DTS, is fixed but can't be handled by a single set of Kconfig settings that apply globally.

(Ab)using the Devicetree and Driver System

ZMK's keymap application layer is the most (in)famous (ab)use of devicetree. In particular, we did this in order to accomplish the following goals:

• Have a declarative syntax for our keymaps, not one that is "my keymap is C code". This was important to design early on so that future/upcoming runtime keymaps (stored to settings subsystem, etc) aren't sacrificing any of the power the existing keymaps have.
• To achieve the declarative keymaps, we wanted a way to assign "custom behaviors" to certain spots in the keymap. That meant having some way to easily reference a standard "reusable behavior" that's available in the system, with optional additional parameters passed "at the point of use". For example, "In this spot in the keymap, it should be a basic HID code press/release", and then passing "HID usage A" as the parameter to pass to the parameter when it is invoked.

To do this, we did the following questionable things:

• We have a custom new "behavior" driver API, that exposes a simple API for press/release of the behavior, that takes a few parameters.
• The bindings for those behaviors include 0-2 possible parameters, available by setting #bindings-cells = <1> property.
• Behaviors can compose other behaviors by having phandle or phandle-array properties that refer to other behaviors!
• Keymaps are then a set of child nodes for each layer of the keymap that have a bindings list that is a phandle-array set of behavior nodes with parameters.

The DTS model gave us the following "for free", which have nothing to do with hardware, but happens to be already integrated into Zephyr nicely:

• A complete syntax for specifying a directed graph of nodes with properties, with schema, node types (compatible), nesting, ability to override properties on existing nodes, etc.
• An existing build system to assembles those files, and spits out a C headerfile, along with a powerful macro system for using that headerfile to generate code linked to those nodes.
• An easy system for linking the nodes to each other when the system runs that matches the graph described in the original syntax (DEVICE_DT_GET, or runtime device_get_binding())

In a nutshell: using the driver system for non-hardware plugin system

Summary

That's the big part of how we do "off label" things with devicetree. I am not here to advocate for anything in particular in terms of Zephyr changes, but would be happy to have some of what we've done have a "proper way" of doing it that doesn't make me cringe sharing it.