All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksii Kurochko <oleksii.kurochko@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: Oleksii Kurochko <oleksii.kurochko@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>
Subject: [RFC PATCH v1 0/1] ARCH_FIXED_CONFIG introduction for randconfig
Date: Thu,  7 Dec 2023 19:03:18 +0200	[thread overview]
Message-ID: <cover.1701966261.git.oleksii.kurochko@gmail.com> (raw)

Brief Overview:
In the earlier patch series [1], it was introduced a comprehensive set of changes
enabling a full Xen build for RISC-V.
This early support primarily provides the minimum stubs required for the RISC-V
Xen build. At this stage of development, many configs are deemed unnecessary and
are expected to be disabled.

Without ARCH_FIXED_CONFIG (or an alternative mechanism), the alternative is
updating CI's build.yaml in multiple instances with the same configs,
mirroring the approach taken in [1] to prevent the inadvertent activation of
unsupported configs.

For example, in scenarios like dom0less, we can exclude grant tables by setting
"CONFIG_GRANT_TABLE=n" in ARCH_FIXED_CONFIG. This eliminates the need for intricate
modifications to Kconfig configurations with conditions like "depends on X86 || ARM"
or the introduction of HAS_* conditions followed by Kconfig updates with
"depends on HAS_*," as illustrated in examples [2] or [3].

It might be useful for other architectures as well, especially for PPC, which is
currently under development.

There are several open questions:
- Does introduction of ARCH_FIXED_CONFIG make sense?
- Should ARCH_FIXED_CONFIG be re-used for *defconfig?

[1] https://lore.kernel.org/xen-devel/b4e85f8f58787b4d179022973ce25673d6b56e36.1700761381.git.oleksii.kurochko@gmail.com/
[2] https://lore.kernel.org/xen-devel/cdc20255540a66ba0b6946ac6d48c11029cd3385.1701453087.git.oleksii.kurochko@gmail.com/
[3] https://lore.kernel.org/xen-devel/d42a34866edc70a12736b5c6976aa1b44b4ebd8a.1701453087.git.oleksii.kurochko@gmail.com/

Oleksii Kurochko (1):
  xen/Makefile: introduce ARCH_FIXED_CONFIG for randconfig

 xen/Makefile | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.43.0



             reply	other threads:[~2023-12-07 17:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 17:03 Oleksii Kurochko [this message]
2023-12-07 17:03 ` [RFC PATCH v1 1/1] xen/Makefile: introduce ARCH_FIXED_CONFIG for randconfig Oleksii Kurochko
2023-12-07 20:17   ` Andrew Cooper
2023-12-07 21:07     ` Oleksii
2023-12-08  1:01       ` Stefano Stabellini
2023-12-08  9:07         ` Oleksii
2023-12-11 15:56     ` Jan Beulich
2023-12-18 14:13       ` Oleksii
2023-12-18 16:07       ` Andrew Cooper
2023-12-18 16:15         ` Jan Beulich
2023-12-19  2:03           ` Stefano Stabellini
2023-12-19 13:11             ` Oleksii

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=cover.1701966261.git.oleksii.kurochko@gmail.com \
    --to=oleksii.kurochko@gmail.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.