Re: [PATCH RFC 6/6] playbooks: add kconfig support

[Luis Chamberlain <mcgrof@kernel.org>]

On Fri, Apr 04, 2025 at 10:33:07PM +0200, Daniel Gomez wrote:
> On Tue, Apr 01, 2025 at 02:02:23PM +0100, Luis Chamberlain wrote:
> > I think this usecase begs for a more basic form of 'make dynconfig', one
> > which we always call.
> 
> The only difference I see is that dynconfig generates a full Kconfig file, while
> this one creates a fragment meant to be merged with an existing .config using
> predefined Kconfig options.

The relationship is a requirement to be generated before existing
Kconfig files. The current kconfig fork maintained by linux-kdevops/kconfig [0]
is maintained as a git subtree inside kdevops so to allow us to not require
those odd git submodule strategy, ie, we maintain all history inside git
and for users they just see the git tree one, not two.

And so the common goal is to be able to try to avoid having to modify
things which can make kconfig independent from Linux's version of kconfig.

[0] https://github.com/linux-kdevops/kconfig

> If I understood dynconfig correctly, then I agree with you. There's no reason
> to declare these in the current Kconfig, unless we want to avoid generating them
> every time. Then we'd need the fragment generation -> merge. Also, the fragment
> generation is much simpler to generate than an entire Kconfig file.

Indeed,

> > If we're going to do that then we can kill two birds with one stone by
> > having info-dynconfig and system-info-dynconfig, where the info-dynconfig
> > consists of targets which won't require root or sudo. This is the part
> > that might be useful to Masahiro, things like your compiler. Then the
> > system-info-dynconfig target can be targets which require sudo or root.
> > In that way, if a user does not want to have local playbooks run sudo
> > they can simply describe their environment with a yaml file as input.
> 
> This works with either option, since both are Ansible playbooks anyway.

Sure.

> > Nix users can also then just describe their system info and and be happy
> > with calling qemu in a simple way, if they don't want libvirt to manage
> > crap for you.
> 
> I'm not sure about this. Can you ellaborate?

OK so for example kdevops today aims to try infer tons of information
from a user's system for libvirt uses. For debian based systems we go so
far as having to use sudo to query the libvirt pools that exist. To many
this is a security push they wish they could avoid. So an alternative to
this is to instruct users by defaul to write down their systems's
information about storage pool information. For nix users the same might
apply so we do not repeat the same history. Instead of "requiring" to
run sudo to check a system's virsh pool, we just go the other way with
nix, and just have the user write down on a file manually where their
virtpool stuff is. Only if they user a special command do we do the
inference hoop which may require sudo. This sort of informaiton is
needed before kconfig starts processign Kconfig files, and so we have
two parts to this, a) new featuers b) existing features. The b) featuers
are like the libvirt pool stuff. While an example of a) is nix OS
suport.

 Luis