kdevops.lists.linux.dev archive mirror
 help / color / mirror / Atom feed

From: Luis Chamberlain <mcgrof@kernel.org>
To: kdevops@lists.linux.dev
Cc: mcgrof@kernel.org, Fan Ni <fan.ni@samsung.com>,
	Jim Harris <jim.harris@samsung.com>
Subject: [kdevops TODO] rationale for kconfig and yaml symbol matching
Date: Mon, 18 Mar 2024 10:25:33 -0700	[thread overview]
Message-ID: <Zfh5DRQmQr9lVe15@bombadil.infradead.org> (raw)

I often provide feedback on random patches about things which may
impact scaling kdevops further. I'd like to highlight and document
the rationale for one which has been long on the TODO list but
I think it would be good to put on record what the plan is and
get other's ideas. This may help explain why we do things like this
and for new developers it will help ensure parity for the goal.

Often we have Kconfig symbols like this new one:

config DEVCONFIG_ENABLE_SYSTEMD_TIMESYNCD_COPY_HOST_TIMEZONE                 

We then have a respective Makefile magic to ensure this gets set to
True, as the respective ansible yaml is False:

ifeq (y,$(CONFIG_DEVCONFIG_ENABLE_SYSTEMD_TIMESYNCD_COPY_HOST_TIMEZONE))
ANSIBLE_EXTRA_ARGS += devconfig_enable_systemd_timesyncd_copy_host_timezone='True'
endif

We then have a respective default in yaml which sets this to False:

devconfig_enable_systemd_timesyncd_copy_host_timezone: False                 

This is what I'd like to see, and the rational is that eventually we
could just modify upstream kconfig, which we share with Linux [0],
so that we can associate a new tag to a symbol to indicate to kconfig
that we want that variable in a  yaml output too. If at least one of
these is defined then an extra_vars.yaml file will be used, and we
could override this with a conf --yaml <name>.

So we just gotta find some time to add support to Kconfig upstream on
the kernel to allow something like this:

config FOO
	<whatever>
	<optional-headers>
	wants_yaml
	<optional-help-description>

The key here is wants_yaml, and if set, we'd have a modifer for each
type of kconfib symbol, string, etc. Then all of Makefiles which check for a
respective bool or string values can be ripped out once this is in, and
we propate this into the shared kconfig.

I suppose we should document some of these things into a TODO file?

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

  Luis

                 reply	other threads:[~2024-03-18 17:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zfh5DRQmQr9lVe15@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=fan.ni@samsung.com \
    --cc=jim.harris@samsung.com \
    --cc=kdevops@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).