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

On 9/2/25 2:49 PM, Konrad Dybcio wrote:
> 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

Just to make sure it's clear - this is not any sort of nak to the patchset

Konrad