From: Julien Grall <julien@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"George Dunlap" <george.dunlap@citrix.com>,
"Ian Jackson" <iwj@xenproject.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 02/23] lib: move 64-bit div/mod compiler helpers
Date: Wed, 7 Apr 2021 15:06:15 +0100 [thread overview]
Message-ID: <42f74b93-1ef2-a3c5-6718-01efd4ffce2c@xen.org> (raw)
In-Reply-To: <75299b2a-9610-57fb-95a3-c49d926af54b@suse.com>
On 07/04/2021 09:33, Jan Beulich wrote:
> On 06.04.2021 21:34, Julien Grall wrote:
>> Hi Jan,
>>
>> On 01/04/2021 16:23, Jan Beulich wrote:
>>> On 01.04.2021 16:56, Julien Grall wrote:
>>>> On 01/04/2021 11:19, Jan Beulich wrote:
>>>>> --- a/xen/common/lib.c
>>>>> +++ b/xen/lib/divmod.c
>>>>> @@ -40,7 +40,6 @@
>>>>> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>>>>> * SUCH DAMAGE.
>>>>> */
>>>>> -#if BITS_PER_LONG == 32
>>>>
>>>> In theory BITS_PER_LONG == 32 is not quite the same as 32-bit arch. Can
>>>> you clarify whether this code is necessary on 64-bit arch where long is
>>>> only 32-bit.
>>>
>>> Likely the compiler can get away without invoking these helpers, so
>>> the code would remain unused. I'm uncertain whether CONFIG_64BIT
>>> ought to be set for such an architecture, as we assume sizeof(long)
>>> == sizeof(void*), and hence pointers would then need to be 32-bit
>>> as well there.
>>
>> This is a fair point. Would you mind to add a sentence explaining that
>> in the commit message?
>
> I've added
>
> "Note that we imply "32-bit arch" to be the same as BITS_PER_LONG == 32,
> i.e. we aren't (not just here) prepared to have a 64-bit arch with
> BITS_PER_LONG == 32. Yet even if we supported such, likely the compiler
> would get away there without invoking these helpers, so the code would
> remain unused in practice."
Sounds fine to me.
>
>> With that:
>>
>> Acked-by: Julien Grall <jgrall@amazon.com>
>
> Thanks. Any chance to also get an ack on patch 1, so at least these two
> (or three, seeing that you also did ack patch 3) could go in before my
> re-posting of the series to add the one line commit message additions
> that you did ask for on all the str* and mem* patches? (Alternatively I
> could take the time and re-order the two.)
I didn't ack #1 because I am not very familiar with the x86 constraints.
If anyone with x86 background (maybe Roger?) is willing to review it,
then I would be happy to give my ack.
Cheers,
--
Julien Grall
next prev parent reply other threads:[~2021-04-07 14:06 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 10:14 [PATCH 00/23] further population of xen/lib/ Jan Beulich
2021-04-01 10:19 ` [PATCH 01/23] lib: move muldiv64() Jan Beulich
2021-04-15 10:00 ` Ping (x86): " Jan Beulich
2021-04-15 12:46 ` Roger Pau Monné
2021-04-01 10:19 ` [PATCH 02/23] lib: move 64-bit div/mod compiler helpers Jan Beulich
2021-04-01 14:56 ` Julien Grall
2021-04-01 15:23 ` Jan Beulich
2021-04-06 19:34 ` Julien Grall
2021-04-07 8:33 ` Jan Beulich
2021-04-07 14:06 ` Julien Grall [this message]
2021-04-01 10:20 ` [PATCH 03/23] string: drop redundant declarations Jan Beulich
2021-04-01 14:59 ` Julien Grall
2021-04-01 10:20 ` [PATCH 04/23] lib: move memset() Jan Beulich
2021-04-01 10:21 ` [PATCH 05/23] lib: move memcpy() Jan Beulich
2021-04-01 10:21 ` [PATCH 06/23] lib: move memmove() Jan Beulich
2021-04-01 10:22 ` [PATCH 07/23] lib: move memcmp() Jan Beulich
2021-04-01 10:22 ` [PATCH 08/23] lib: move memchr() Jan Beulich
2021-04-01 10:23 ` [PATCH 09/23] lib: move memchr_inv() Jan Beulich
2021-04-01 10:23 ` [PATCH 10/23] lib: move strlen() Jan Beulich
2021-04-01 10:23 ` [PATCH 11/23] lib: move strnlen() Jan Beulich
2021-04-01 10:24 ` [PATCH 12/23] lib: move strcmp() Jan Beulich
2021-04-01 10:25 ` [PATCH 13/23] lib: move strncmp() Jan Beulich
2021-04-01 10:25 ` [PATCH 14/23] lib: move strlcpy() Jan Beulich
2021-04-01 10:25 ` [PATCH 15/23] lib: move strlcat() Jan Beulich
2021-04-01 10:25 ` [PATCH 16/23] lib: move strchr() Jan Beulich
2021-04-01 10:26 ` [PATCH 17/23] lib: move strrchr() Jan Beulich
2021-04-01 10:26 ` [PATCH 18/23] lib: move strstr() Jan Beulich
2021-04-01 10:26 ` [PATCH 19/23] lib: move strcasecmp() Jan Beulich
2021-04-01 10:27 ` [PATCH 20/23] lib: move/rename strnicmp() to strncasecmp() Jan Beulich
2021-04-01 10:27 ` [PATCH 21/23] lib: move strspn() Jan Beulich
2021-04-01 10:28 ` [PATCH 22/23] lib: move strpbrk() Jan Beulich
2021-04-01 10:28 ` [PATCH 23/23] lib: move strsep() Jan Beulich
2021-04-01 11:54 ` [PATCH 00/23] further population of xen/lib/ Julien Grall
2021-04-01 13:43 ` Jan Beulich
2021-04-01 14:04 ` Julien Grall
2021-04-01 14:27 ` Jan Beulich
2021-04-01 14:55 ` Julien Grall
2021-04-01 15:25 ` Jan Beulich
2021-04-01 15:32 ` Julien Grall
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=42f74b93-1ef2-a3c5-6718-01efd4ffce2c@xen.org \
--to=julien@xen.org \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=jbeulich@suse.com \
--cc=roger.pau@citrix.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.