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

[Luis Chamberlain <mcgrof@kernel.org>]

On Mon, Mar 31, 2025 at 08:31:55PM +0200, Daniel Gomez wrote:
> On Mon, Mar 31, 2025 at 12:32:29AM +0100, Luis Chamberlain wrote:
> > On Mon, Mar 31, 2025 at 08:54:59AM +0200, Daniel Gomez wrote:
> > > On Fri, Mar 28, 2025 at 03:58:50PM +0100, Luis Chamberlain wrote:
> > > > On Fri, Mar 28, 2025 at 08:56:19PM +0000, Daniel Gomez wrote:
> > > > > From: Daniel Gomez <da.gomez@samsung.com>
> 
> > > I think merging all generated variables into Kconfig makes this a bit easier as
> > > we don't have to deal with another Ansible YAML file. Ideally, we would merge
> > > this new YAML with the Kconfig YAML output. Can this be done? Makes sense?
> > 
> > Yes. We have:
> > 
> > Kconfig -->
> > .config --> optional output yaml --> 1st.yaml
> >         |
> > 	|
> > 	v------- what we need -----> 2nd.yaml
> > 	|
> > 	|
> > 	v--------------------------> extra_vars.yaml
> > 	
> > 
> > Is that right?
> 
> I was thinking this instead:
> 
> What we have (please, correct if it's wrong):
> 
> Kconfig --> .config
>         --> .extra_vars_auto.yaml --> Makefile --> extra_vars.yaml --> Ansible
> 
> What I'm suggesting above:
> 
> Makefile --> Ansible --> env.yaml                                                                                             |
>                      --> env.config (Kconfig fragment) --> Kconfig --> .config                                                v
>                                                                    --> .extra_vars_auto.yaml --> Makefile --> extra_vars.yaml --> Ansible
> 
> But looking at this, do you see a way to simplify this?

Ah yes.

The 'make dynconfig' support already does this but it we currently only
use it it to scrape your PCI tree to support PCI passthrough through
Kconfig support.

It was built to grow, so for example in the future I've hinted before we
could use cloud tools to scrape your cloud options and so to generate
Kconfig files automatically for us, instead of us having to write each
entry.

I think this usecase begs for a more basic form of 'make dynconfig', one
which we always call.

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.

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.

Thoughts?

  Luis