All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksii <oleksii.kurochko@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	 Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	 George Dunlap <george.dunlap@citrix.com>, Wei Liu <wl@xen.org>,
	Shawn Anastasio <sanastasio@raptorengineering.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 13/14] xen: ifdef inclusion of <asm/grant_table.h> in <xen/grant_table.h>
Date: Tue, 28 Nov 2023 11:28:45 +0200	[thread overview]
Message-ID: <195a50316efde86113f6f5df269c754a90490c57.camel@gmail.com> (raw)
In-Reply-To: <405c2d66-a6f4-4bbb-ada5-2ac49c8c9744@suse.com>

On Tue, 2023-11-28 at 08:57 +0100, Jan Beulich wrote:
> On 27.11.2023 20:38, Oleksii wrote:
> > On Mon, 2023-11-27 at 15:41 +0100, Jan Beulich wrote:
> > > On 27.11.2023 15:13, Oleksii Kurochko wrote:
> > > > --- a/xen/arch/ppc/include/asm/grant_table.h
> > > > +++ /dev/null
> > > > @@ -1,5 +0,0 @@
> > > > -/* SPDX-License-Identifier: GPL-2.0-only */
> > > > -#ifndef __ASM_PPC_GRANT_TABLE_H__
> > > > -#define __ASM_PPC_GRANT_TABLE_H__
> > > > -
> > > > -#endif /* __ASM_PPC_GRANT_TABLE_H__ */
> > > 
> > > Removing this header would be correct only if GRANT_TABLE had a
> > > "depends on
> > > !PPC", I'm afraid. Recall that the earlier randconfig adjustment
> > > in
> > > CI was
> > > actually requested to be undone, at which point what an arch's
> > > defconfig
> > > says isn't necessarily what a randconfig should use.
> > We can do depends on !PPC && !RISCV but shouldn't it be enough only
> > to
> > turn CONFIG_GRANT_TABLE off in defconfig and set
> > CONFIG_GRANT_TABLE=n
> > in EXTRA_XEN_CONFIG?
> 
> That _might_ be sufficient for CI, but we shouldn't take CI as the
> only
> thing in the world. Personally I consider any kind of overriding for,
> in particular, randconfig at bets bogus. Whatever may not be selected
> (or must be selected) should be arranged for by Kconfig files
> themselves.
> That said, there may be _rare_ exceptions. But what PPC's and RISC-
> V's
> defconfig-s have right now is more than "rare" imo.
> 
> > Some time ago I also tried to redefine "Config GRANT_TABLE" in
> > arch-
> > specific Kconfig + defconfig + EXTRA_XEN_CONFIG and it works for
> > me.
> > Could it be solution instead of "depends on..." ?
> 
> Why would we want to re-define an setting? There wants to be one
> single
> place where a common option is defined. Or maybe I don't understand
> what you're suggesting ...
I just thought this change is temporary because grant_table.h will be
introduced later or earlier, and it will be needed to remove "depends
on !PPC && !RISCV". And not to litter common KConfig with the change
which will be removed, it will be better to redefine it in arch-
specific Kconfig with default n.

But after your words about one place, I realized that it would be
better to update a place where a common option is defined.

The only thing I would like to change is probably it will be better to
do the opposite, add "depends on" arches that support
CONFIG_GRANT_TABLE now so it will not need to update "depends on" for
new arches or arches that don't support CONFIG_GRANT_TABLE.

> 
> > One more question I have do we really need this randconfig? On
> > RISC-V
> > side, I launched several time this patch series ( from v1 to v4 +
> > runs
> > during test of patch series ) and I haven't faced case
> > when CONFIG_GRANT_TABLE=n. ( but I turned the config off in
> > defconfig +
> > EXTRA_XEN_CONFIG ).
> 
> That override is why in CI you wouldn't see an issue. But as said -
> CI
> isn't everything.
From this point of view it will be better to add "depends on !PPC &&
!RISCV" to "Config GRANT_TABLE".


~ Oleksii


  reply	other threads:[~2023-11-28  9:29 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27 14:13 [PATCH v4 00/14] Introduce generic headers Oleksii Kurochko
2023-11-27 14:13 ` [PATCH v4 01/14] xen/asm-generic: introduce stub header paging.h Oleksii Kurochko
2023-11-28 21:16   ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 02/14] xen/asm-generic: introduce generic device.h Oleksii Kurochko
2023-11-27 14:31   ` Jan Beulich
2023-11-27 19:46     ` Oleksii
2023-11-28  7:51       ` Jan Beulich
2023-11-28 21:36       ` Shawn Anastasio
2023-11-28 21:28   ` Shawn Anastasio
2023-11-29  8:16     ` Jan Beulich
2023-11-29 12:49     ` Oleksii
2023-11-29 19:18       ` Shawn Anastasio
2023-11-30 12:48         ` Oleksii
2023-11-27 14:13 ` [PATCH v4 03/14] xen/asm-generic: introduce generic hypercall.h Oleksii Kurochko
2023-11-28 21:47   ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 04/14] xen/asm-generic: introduce generic header iocap.h Oleksii Kurochko
2023-11-28 21:50   ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 05/14] xen/asm-generic: introduce stub header <asm/random.h> Oleksii Kurochko
2023-11-28 21:51   ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 06/14] xen/asm-generic: introduce generic header percpu.h Oleksii Kurochko
2023-11-27 14:33   ` Jan Beulich
2023-11-28 21:58   ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 07/14] xen/asm-generic: introduce generalized hardirq.h Oleksii Kurochko
2023-11-28 22:01   ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 08/14] xen/asm-generic: introduce generic div64.h header Oleksii Kurochko
2023-11-28 22:07   ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 09/14] xen/asm-generic: introduce generic header altp2m.h Oleksii Kurochko
2023-11-28 22:09   ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 10/14] xen/asm-generic: introduce stub header monitor.h Oleksii Kurochko
2023-11-28 22:21   ` Shawn Anastasio
2023-11-29  8:19     ` Jan Beulich
2023-11-29  8:21       ` Jan Beulich
2023-11-29 12:41         ` Oleksii
2023-11-29 12:39     ` Oleksii
2023-11-29 19:27       ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 11/14] xen/asm-generic: introduce stub header numa.h Oleksii Kurochko
2023-11-27 14:35   ` Jan Beulich
2023-11-29 19:49   ` Shawn Anastasio
2023-11-30 12:49     ` Oleksii
2023-11-27 14:13 ` [PATCH v4 12/14] xen/asm-generic: introduce stub header softirq.h Oleksii Kurochko
2023-11-27 14:36   ` Jan Beulich
2023-11-27 19:39     ` Oleksii
2023-11-29 19:54   ` Shawn Anastasio
2023-11-29 20:04   ` Shawn Anastasio
2023-11-27 14:13 ` [PATCH v4 13/14] xen: ifdef inclusion of <asm/grant_table.h> in <xen/grant_table.h> Oleksii Kurochko
2023-11-27 14:41   ` Jan Beulich
2023-11-27 19:38     ` Oleksii
2023-11-28  7:57       ` Jan Beulich
2023-11-28  9:28         ` Oleksii [this message]
2023-11-28  9:58           ` Jan Beulich
2023-11-28 11:49             ` Oleksii
2023-11-28 12:53               ` Jan Beulich
2023-11-28 13:28                 ` Oleksii
2023-11-27 14:13 ` [PATCH v4 14/14] xen/asm-generic: ifdef inclusion of <asm/mem_access.h> Oleksii Kurochko
2023-11-27 14:43   ` Jan Beulich
2023-11-29  9:25 ` [PATCH v4 00/14] Introduce generic headers Jan Beulich
2023-11-29 12:32   ` 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=195a50316efde86113f6f5df269c754a90490c57.camel@gmail.com \
    --to=oleksii.kurochko@gmail.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sanastasio@raptorengineering.com \
    --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.