Re: [PATCH 0/3] Add configuration fragment support to kdevops

[Daniel Gomez <da.gomez@kernel.org>]

On 18/09/2025 23.19, Luis Chamberlain wrote:
> On Wed, Sep 17, 2025 at 02:29:17PM +0200, Daniel Gomez wrote:
>> This series introduces Linux kernel-style configuration fragment support
>> to kdevops, enabling flexible configuration composition and better
>> maintainability.
>>
>> * Import merge_config.sh from Linux kernel for fragment merging
>> * Update scripts/config with latest upstream fixes (v5.11 -> v6.15)
>> * Add practical VM configuration fragments for guest scaling
>>
>> Benefits:
>> - Modular configuration: Compose complex configs from reusable fragments
>> - Better maintainability: Separate concerns (VM sizing, features, workflows)
>> - Flexible deployment: Mix and match fragments for different scenarios
>> - Upstream compatibility: Uses standard Linux kernel tooling
>>
>> Usage example:
>>
>> * Minimal development VM + diy enablement:
>> make dynamic_pcipassthrough_kconfig KDEVOPS_ENABLE_PCIE_KCONFIG=1
>> make defconfig-sysbench-mysql-atomic-tps-variability
>> ./scripts/kconfig/merge_config.sh -n .config \
>>     ./defconfigs/configs/vm2g2c.config
>>     ./defconfigs/configs/diy.config \
>>
>> This builds on the kconfig environment discussion [1] and provides an
>> alternative to the SAT solver solution.
>>
>> Link: https://lore.kernel.org/kdevops/20250704-b4-params-v1-1-42dd4ff478b3@samsung.com/ [1]
>>
>> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> 
> This is nice, but does it scale? I don't think so.

100%. That said, there isn't much difference between our defconfigs/* and
fragments. A fragment is simply a reusable piece of configuration that we
repeat across all defconfigs. For example, this allows users to combine xfs
defconfigs + vm configuration. 


> So my ask would be to
> see if you can integrate the pico SAT patches to our shared kconfig tree
> tree first under a new branch which branches out of the origin/yamlconfig
> branch. Then merge that to kdevops and evaluate what a true SAT solver
> can do. This let's us essentially lead the way forward for Linux.


I already have higher priority tasks on my plate right now (CI). Let's make a plan instead. 
I believe Chuck was putting together a task list for terraform. Would it help to have
a global backlog for tasks to do? 

> 
> The experiences we learn can be brought back to Linux.
> 
>   Luis