From: Oleksii <oleksii.kurochko@gmail.com>
To: Julien Grall <julien@xen.org>, xen-devel@lists.xenproject.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Jan Beulich <jbeulich@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
Bertrand Marquis <bertrand.marquis@arm.com>,
Michal Orzel <michal.orzel@amd.com>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
Shawn Anastasio <sanastasio@raptorengineering.com>
Subject: Re: [PATCH] xen/lib: introduce generic find next bit operations
Date: Fri, 26 Jan 2024 17:58:49 +0200 [thread overview]
Message-ID: <1104df46d7780ef1bbcb6c745685b10fe6d2aa5d.camel@gmail.com> (raw)
In-Reply-To: <f8602dc5-e603-42fc-b3a2-dc71c55db341@xen.org>
On Fri, 2024-01-26 at 13:20 +0000, Julien Grall wrote:
> Hi,
Hi Julien,
>
> On 26/01/2024 12:20, Oleksii Kurochko wrote:
> > find-next-bit.c is common for Arm64, PPC and RISCV64,
> > so it is moved to xen/lib.
> >
> > Suggested-by: Jan Beulich <jbeulich@suse.com>
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
> > ---
> > docs/misra/exclude-list.json | 4 -
> > xen/arch/arm/arm64/lib/Makefile | 2 +-
> > xen/arch/arm/include/asm/arm64/bitops.h | 48 --------
> > xen/arch/ppc/include/asm/bitops.h | 115 -------------
> > -----
> > xen/include/xen/bitops.h | 48 ++++++++
> > xen/lib/Makefile | 1 +
> > .../find_next_bit.c => lib/find-next-bit.c} | 0
> > 7 files changed, 50 insertions(+), 168 deletions(-)
> > rename xen/{arch/arm/arm64/lib/find_next_bit.c => lib/find-next-
> > bit.c} (100%)
> >
> > diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-
> > list.json
> > index 7971d0e70f..7fe02b059d 100644
> > --- a/docs/misra/exclude-list.json
> > +++ b/docs/misra/exclude-list.json
> > @@ -13,10 +13,6 @@
> > "rel_path": "arch/arm/arm64/insn.c",
> > "comment": "Imported on Linux, ignore for now"
> > },
> > - {
> > - "rel_path": "arch/arm/arm64/lib/find_next_bit.c",
>
> Rather than removing the section, I was expecting the rel_path to be
> updated. Can you explain why you think the exclusion is not
> necessary?
I considered simply updating the path to xen/lib/find-next-bit.c, but
ultimately opted to remove it. This decision was based on the fact that
the line in question checks for a file that no longer exists. If it's
preferable to update the rel_path with xen/lib/find-next-bit.c, I'm
more than willing to make that adjustment.
>
> > - "comment": "Imported from Linux, ignore for now"
> > - },
> > {
> > "rel_path": "arch/x86/acpi/boot.c",
> > "comment": "Imported from Linux, ignore for now"
> > diff --git a/xen/arch/arm/arm64/lib/Makefile
> > b/xen/arch/arm/arm64/lib/Makefile
> > index 1b9c7a95e6..66cfac435a 100644
> > --- a/xen/arch/arm/arm64/lib/Makefile
> > +++ b/xen/arch/arm/arm64/lib/Makefile
> > @@ -1,4 +1,4 @@
> > obj-y += memcpy.o memcmp.o memmove.o memset.o memchr.o
> > obj-y += clear_page.o
> > -obj-y += bitops.o find_next_bit.o
> > +obj-y += bitops.o
> > obj-y += strchr.o strcmp.o strlen.o strncmp.o strnlen.o strrchr.o
> > diff --git a/xen/arch/arm/include/asm/arm64/bitops.h
> > b/xen/arch/arm/include/asm/arm64/bitops.h
> > index d85a49bca4..f9dd066237 100644
> > --- a/xen/arch/arm/include/asm/arm64/bitops.h
> > +++ b/xen/arch/arm/include/asm/arm64/bitops.h
> > @@ -36,57 +36,9 @@ static inline int flsl(unsigned long x)
> >
> > /* Based on linux/include/asm-generic/bitops/find.h */
> >
> > -#ifndef find_next_bit
> > -/**
> > - * find_next_bit - find the next set bit in a memory region
> > - * @addr: The address to base the search on
> > - * @offset: The bitnumber to start searching at
> > - * @size: The bitmap size in bits
> > - */
> > -extern unsigned long find_next_bit(const unsigned long *addr,
> > unsigned long
> > - size, unsigned long offset);
> > -#endif
> > -
> > -#ifndef find_next_zero_bit
> > -/**
> > - * find_next_zero_bit - find the next cleared bit in a memory
> > region
> > - * @addr: The address to base the search on
> > - * @offset: The bitnumber to start searching at
> > - * @size: The bitmap size in bits
> > - */
> > -extern unsigned long find_next_zero_bit(const unsigned long *addr,
> > unsigned
> > - long size, unsigned long offset);
> > -#endif
> > -
> > -#ifdef CONFIG_GENERIC_FIND_FIRST_BIT
> > -
> > -/**
> > - * find_first_bit - find the first set bit in a memory region
> > - * @addr: The address to start the search at
> > - * @size: The maximum size to search
> > - *
> > - * Returns the bit number of the first set bit.
> > - */
> > -extern unsigned long find_first_bit(const unsigned long *addr,
> > - unsigned long size);
> > -
> > -/**
> > - * find_first_zero_bit - find the first cleared bit in a memory
> > region
> > - * @addr: The address to start the search at
> > - * @size: The maximum size to search
> > - *
> > - * Returns the bit number of the first cleared bit.
> > - */
> > -extern unsigned long find_first_zero_bit(const unsigned long
> > *addr,
> > - unsigned long size);
> > -#else /* CONFIG_GENERIC_FIND_FIRST_BIT */
> > -
> > #define find_first_bit(addr, size) find_next_bit((addr), (size),
> > 0)
> > #define find_first_zero_bit(addr, size)
> > find_next_zero_bit((addr), (size), 0)
> >
> > -#endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
>
> AFAICT, you are changing the behavior for Arm64 without explaining
> why.
> Before, it was possible to set CONFIG_GENERIC_FIND_FIRST_BIT so the
> generic version of find_first_*_bit are used. This is not possible
> anymore with your change.
>
> Looking at Linux, I see that arm64 is now selecting
> GENERIC_FIND_FIRST_BIT (see [1]). So I would argue, we should not
> define
> find_first_bit(). That said, that's probably a separate patch.
>
> For now, you want to explain why GENERIC_FIND_FIRST_BIT is dropped.
I chose to remove it because I couldn't find any usage or configuration
setting for this in Xen (Arm).
I can add "#ifdef GENERIC_FIND_FIRST_BIT" around find_first_zero_bit()
and find_first_bit() in xen/bitops.h, and according to the link [1], it
should be wrapped with ifdef. Perhaps it would be better to use "#if
defined(GENERIC_FIND_FIRST_BIT) && defined(CONFIG_ARM_64)".
My only concern is that it might seem somewhat inconsistent with the
other find_*_bit() functions added in this patch. Should we be care
about that? I mean that do we need similar config or it would be enough
to add a comment why it is necessary to have ifdef
GENERIC_FIND_FIRST_BIT.
~ Oleksii
>
> [1]
> https://lore.kernel.org/linux-arch/20210225135700.1381396-1-yury.norov@gmail.com/
>
next prev parent reply other threads:[~2024-01-26 15:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 12:20 [PATCH] xen/lib: introduce generic find next bit operations Oleksii Kurochko
2024-01-26 13:20 ` Julien Grall
2024-01-26 15:58 ` Oleksii [this message]
2024-01-26 16:08 ` Julien Grall
2024-01-29 7:48 ` Jan Beulich
2024-01-29 11:07 ` 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=1104df46d7780ef1bbcb6c745685b10fe6d2aa5d.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.