Re: [PATCH 0/3] Add configuration fragment support to kdevops
Daniel Gomez <[email protected]>
| Newsgroups | dev.linux.lists.kdevops |
|---|---|
| Organization | kernel.org |
| Message-ID | <[email protected]> |
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/[email protected]/ [1] >> >> Signed-off-by: Daniel Gomez <[email protected]> > > 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