Re: [PATCH v3 0/4] Introduce fdt_overlay_merge() to allow merge of overlay blobs

On 9/2/25 12:35 PM, Wasim Nazir wrote:
> [...]
>>>
>>> Our repositores are following android structure based on android-treble
>>> where vendor subsystems needs to be modular for ease of OTA upgrade and
>>> development.
>>>
>>> As a result of which each feature/techpack (viz. audio, video etc.) have
>>> its own independent repositories where it can build its modules and
>>> overlay DT (soc & board).
>>> Kernel is separate and provides only the core images and base DT (soc &
>>> board).
>>
>> The build system should serve the needs of the project, not the other
>> way around.  If the feature repos can emit a dtbo, why can't they emit
>> a dts as well?
>>
>>> So, dtbo is the option to build it independently and at last we have
>>> options to either "overlay all dtbo at boot-time" or "merge it at build-time and
>>> overlay final dtbo at boot-time".
>>>
>>> This build-time merge is done outside techpack build system.
>>> But if we want to have dts from each techpack, then techpack-build system needs
>>> to communicate somehow to know which dts to include with which base dts.
>>
>> Why is that a harder problem than knowing which dtbo?  The dtbo must
>> have been built from some sort of dts, no?
>>
>>> This is not possible at build-time between techpacks.
>>
>> The build system is not immutable - you're proposing changes to libfdt
>> and/or dtc; why not changes to the build system?
>>
> 
> Hi David,
> 
> As each techpack operates in a sandboxed environment with its own build
> structure, all dependencies are managed within that sandbox, so the
> techpack owner only needs to focus on their own module. Since each
> techpack produces a compiled DTBO, it is self-contained and can be
> merged with other DTBOs without additional coordination.
> 
> If we were to use DTS files instead, every techpack owner would need to
> be involved in resolving cross-dependencies, which is not scalable in
> our modular setup.

+CC Couple of probably interested folks

My slightly-related $0.05 are that the whole concept of compartmentalizing
DT development like this makes any sort of uniformity, common style or
overall coherence of platform description impossible, as each team
inadvertently develops tunnel vision of their slice of the SoC/board, with
the only tangible benefit being a smaller LoC-per-reviewer ratio (that is,
unless the same person gets assigned to review multiple compartments..)

This works when you just need DT to convince the OS to bind the resources
to a driver, but actively prevents developers from catching anti-patterns
and/or abuses before they arise

Konrad