From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
consulting@bugseng.com,
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: [XEN PATCH v3 3/3] xen/mm: add declaration for first_valid_mfn
Date: Thu, 14 Dec 2023 09:49:01 +0100 [thread overview]
Message-ID: <0d7901b9a9cbc7c23514ca977af3a66e@bugseng.com> (raw)
In-Reply-To: <2a7f0d03-1cab-4824-86ae-fb7a26ff8adc@suse.com>
On 2023-12-14 08:53, Jan Beulich wrote:
> On 14.12.2023 03:05, Stefano Stabellini wrote:
>> On Wed, 13 Dec 2023, Jan Beulich wrote:
>>> On 11.12.2023 10:14, Nicola Vetrini wrote:
>>>> --- a/xen/arch/arm/include/asm/numa.h
>>>> +++ b/xen/arch/arm/include/asm/numa.h
>>>> @@ -2,8 +2,9 @@
>>>> #define __ARCH_ARM_NUMA_H
>>>>
>>>> #include <xen/mm.h>
>>>
>>> With this, ...
>>>
>>>> +#include <xen/types.h>
>>>>
>>>> -typedef u8 nodeid_t;
>>>> +typedef uint8_t nodeid_t;
>>>>
>>>> #ifndef CONFIG_NUMA
>>>>
>>>> @@ -12,10 +13,9 @@ typedef u8 nodeid_t;
>>>> #define node_to_cpumask(node) (cpu_online_map)
>>>>
>>>> /*
>>>> - * TODO: make first_valid_mfn static when NUMA is supported on Arm,
>>>> this
>>>> - * is required because the dummy helpers are using it.
>>>> + * TODO: define here first_valid_mfn as static when NUMA is
>>>> supported on Arm,
>>>> + * this is required because the dummy helpers are using it.
>>>> */
>>>> -extern mfn_t first_valid_mfn;
>>>
>>> ... and this declaration moved to xen/mm.h, how is it going to be
>>> possible
>>> to do as the adjusted comment says? The compiler will choke on the
>>> static
>>> after having seen the extern.
>>
>> Nicola was just following a review comment by Julien. NUMA has been
>> pending for a while and I wouldn't hold this patch back because of it.
>> I suggest we go with Julien's request (this version of the patch).
>>
>> If you feel strongly about it, please suggest an alternative.
>
> Leaving a TODO comment which cannot actually be carried out is just
> wrong
> imo. And I consider in unfair to ask me to suggest an alternative. The
> (imo obvious) alternative is to drop this patch, if no proper change
> can
> be proposed. There's nothing wrong with leaving a violation in place,
> when that violation is far from causing any kind of harm. The more that
> the place is already accompanied by a (suitable afaict) comment.
>
> Jan
I have a proposal: deviate first_valid_mfn as a deliberate workaround to
NUMA not being supported on ARM and PPC. This still supplies a
justification and does not imply any other code change.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
prev parent reply other threads:[~2023-12-14 8:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-11 9:14 [XEN PATCH v3 0/3] address some violations of MISRA C Rule 8.4 Nicola Vetrini
2023-12-11 9:14 ` [XEN PATCH v3 1/3] xen/x86: add missing instances of asmlinkage attributes Nicola Vetrini
2023-12-12 1:48 ` Stefano Stabellini
2023-12-18 14:03 ` Jan Beulich
2023-12-11 9:14 ` [XEN PATCH v3 2/3] x86/viridian: make build_assertions static Nicola Vetrini
2023-12-11 9:15 ` Durrant, Paul
2023-12-11 9:14 ` [XEN PATCH v3 3/3] xen/mm: add declaration for first_valid_mfn Nicola Vetrini
2023-12-12 23:24 ` Stefano Stabellini
2023-12-13 8:26 ` Jan Beulich
2023-12-14 2:05 ` Stefano Stabellini
2023-12-14 7:53 ` Jan Beulich
2023-12-14 8:32 ` Julien Grall
2023-12-14 8:51 ` Jan Beulich
2023-12-14 14:15 ` George Dunlap
2023-12-14 19:10 ` Julien Grall
2023-12-14 21:27 ` Stefano Stabellini
2023-12-15 8:03 ` Jan Beulich
2023-12-15 9:43 ` Julien Grall
2023-12-15 9:59 ` Nicola Vetrini
2023-12-15 10:06 ` Julien Grall
2023-12-15 21:01 ` Stefano Stabellini
2023-12-14 8:49 ` Nicola Vetrini [this message]
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=0d7901b9a9cbc7c23514ca977af3a66e@bugseng.com \
--to=nicola.vetrini@bugseng.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=bertrand.marquis@arm.com \
--cc=consulting@bugseng.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.