From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.86_2) id 1hqtK6-0003W5-UF for mharc-qemu-riscv@gnu.org; Fri, 26 Jul 2019 02:03:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51290) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqtK4-0003Vu-6d for qemu-riscv@nongnu.org; Fri, 26 Jul 2019 02:03:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hqtK2-0003Le-0N for qemu-riscv@nongnu.org; Fri, 26 Jul 2019 02:03:20 -0400 Received: from smtpe1.intersmtp.com ([213.121.35.71]:57753) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hqtJu-0002vb-Gx; Fri, 26 Jul 2019 02:03:10 -0400 Received: from tpw09926dag18e.domain1.systemhost.net (10.9.212.18) by BWP09926076.bt.com (10.36.82.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Fri, 26 Jul 2019 07:03:05 +0100 Received: from tpw09926dag18e.domain1.systemhost.net (10.9.212.18) by tpw09926dag18e.domain1.systemhost.net (10.9.212.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Jul 2019 07:03:05 +0100 Received: from tpw09926dag18e.domain1.systemhost.net ([fe80::a946:6348:ccf4:fa6c]) by tpw09926dag18e.domain1.systemhost.net ([fe80::a946:6348:ccf4:fa6c%12]) with mapi id 15.00.1395.000; Fri, 26 Jul 2019 07:03:05 +0100 From: To: , CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , Thread-Topic: [Qemu-devel] [PATCH v4 02/15] memory: Access MemoryRegion with MemOp Thread-Index: AQHVQs6us5Ke12ptjEW1c49AzysqcKbbJooAgAE/RY4= Date: Fri, 26 Jul 2019 06:03:05 +0000 Message-ID: <1564120985317.14967@bt.com> References: <45d1ebe4b2ed4c039c9da20a738652df@tpw09926dag18e.domain1.systemhost.net> <1564048354001.54262@bt.com>, In-Reply-To: Accept-Language: en-AU, en-GB, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.42] Content-Type: multipart/alternative; boundary="_000_156412098531714967btcom_" MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 213.121.35.71 Subject: Re: [Qemu-riscv] [Qemu-devel] [PATCH v4 02/15] memory: Access MemoryRegion with MemOp X-BeenThere: qemu-riscv@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2019 06:03:22 -0000 --_000_156412098531714967btcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 7/25/19 9:45 PM, Philippe Mathieu-Daud=E9 wrote: >On 7/25/19 11:52 AM, tony.nguyen@bt.com wrote: >> Replacing size with size+sign+endianness (MemOp) will enable us to >> collapse the two byte swaps, adjust_endianness and handle_bswap, along >> the I/O path. >> >> While interfaces are converted, callers will have existing unsigned >> size coerced into a MemOp, and the callee will use this MemOp as an >> unsigned size. >> >> Signed-off-by: Tony Nguyen >> --- >> include/exec/memop.h | 4 ++++ >> include/exec/memory.h | 9 +++++---- >> memory.c | 7 +++++-- >> 3 files changed, 14 insertions(+), 6 deletions(-) >> >> diff --git a/include/exec/memop.h b/include/exec/memop.h >> index ac58066..09c8d20 100644 >> --- a/include/exec/memop.h >> +++ b/include/exec/memop.h >> @@ -106,4 +106,8 @@ typedef enum MemOp { >> MO_SSIZE =3D MO_SIZE | MO_SIGN, >> } MemOp; >> >> +/* No-op while memory_region_dispatch_[read|write] is converted to MemO= p */ >> +#define MEMOP_SIZE(op) (op) /* MemOp to size. */ >> +#define SIZE_MEMOP(ul) (ul) /* Size to MemOp. */ > >SIZE_MEMOP() is never used until patch #10 "memory: Access MemoryRegion >with MemOp semantics", it would be clearer to only introduce the >MEMOP_SIZE() no-op here, and directly introduce the correct SIZE_MEMOP() >macro in patch #10. SIZE_MEMOP() is used, and is the main change, in patches #3 to #10. Perhaps= you meant MEMOP_SIZE()? Either way, you have raised an issue :) There is a lack of clarity in how the two macros are used to update the interfaces.? --_000_156412098531714967btcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

On 7/25/19 9:45 PM, Philippe Mathieu-Daud=E9 wrote: 
>On 7/25/19 11:52 AM, tony.nguyen@bt.com wrote:
>> Replacing size with size+sign+endianness (MemOp) will= enable us to
>> collapse the two byte swaps, adjust_endianness and handle_bsw= ap, along
>> the I/O path.
>> 
>> While interfaces are converted, callers will have existing un= signed
>> size coerced into a MemOp, and the callee will use this MemOp= as an
>> unsigned size.
>> 
>> Signed-off-by: Tony Nguyen <tony.nguyen@bt.com>
>> ---
>>  include/exec/memop.h  | 4 ++++
>>  include/exec/memory.h | 9 +++++----=
>>  memory.c             &nbs= p;| 7 +++++--
>>  3 files changed, 14 insertions(+), 6 deletions(-)
>> 
>> diff --git a/include/exec/memop.h b/include/exec/memop.h
>> index ac58066..09c8d20 100644
>> --- a/include/exec/memop.h
>> +++ b/include/exec/memop.h
>> @@ -106,4 +106,8 @@ typedef enum MemOp {
>>      MO_SSIZE =3D MO_SIZE | MO_SIGN,
>>  } MemOp;
>> 
>> +/* No-op while memory_region_dispatch_[read|write] is co= nverted to MemOp */
>> +#define MEMOP_SIZE(op)  (op)    /* MemOp = to size.  */
>> +#define SIZE_MEMOP(ul)  (ul)    /* Size t= o MemOp.  */
>
>SIZE_MEMOP() is never used until patch #10 "memory: Access Me= moryRegion
>with MemOp semantics", it would be clearer to only introduce = the
>MEMOP_SIZE() no-op here, and directly introduce the correct SIZE_M= EMOP()
>macro in patch #10.

SIZE_MEMOP() is used, and is the main change, in patches #3 to #10. Pe= rhaps you
meant MEMOP_SIZE()?

Either way, you have raised an issue :)

There is a lack of clarity in how the two macros are used to update th= e
interfaces.​


--_000_156412098531714967btcom_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a5d:51d0:0:0:0:0:0 with SMTP id n16csp11478691wrv; Thu, 25 Jul 2019 23:03:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqwZ/aE50nyZInQKb9z5R0HgfjLDjzlVkwZsdAaXnK2KeS93A59kKDhqcxxfXP8WbY0Zj0dj X-Received: by 2002:ad4:4373:: with SMTP id u19mr67516757qvt.202.1564121011721; Thu, 25 Jul 2019 23:03:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564121011; cv=none; d=google.com; s=arc-20160816; b=NHe+Cx1NUwV5qrQLpvmWWTeuPeQMhtHpVb/HqQrFHl5jVWyhDBgw07JJ5VoDGs9HBa 1ZHY+D4qEFT1yw6/Jrm/UUph8r5D86p1W/4lJAe98yqHNXSlDk9/vLj4PbyOHRTNokAY Epx2sBoUAyY/OCyYJ+BYEoeZ2Y+rJT20WjiDCsToqvppiTpELpT4smYSBS3Juu5OMcM0 MiBp5r/RlbcMUgC9oyVACicv2t3L6GxZhaB6nX4hMLMIpAHwRczA6nRUIjkPfu7d3njg RHdd7EkPD4C/0okB32a44pNDapTtmeidgMneaVutHhZtPmeew9yg3VEjYUsBXvhztlfQ 6koA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:cc:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject:mime-version :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:to:from; bh=b+p8otFpVNHnyjlC+YMEi0EH9ns+NWALrj2jCIZeXaY=; b=A/U+GO+K5RDvn2QQ9dl3EeUwv1KkYmLYDIHS28SVUlw+2ijaDob8NUL8W4i0KHH5uL qiVsJkSYI2TJ2pU6VbdQxb9CjYRP8mIY48aqV/L+hEZmfYmYs8r/DvSmvSnf6FEL4v13 2kkxVBzxwAbfbcv3J8a9naGuv5tdB7VpSjGnbx6TqLIRFJ9SKxsn6EvK3MIY8Yo4uwVk 1+UiTqleUppsMs0XUdx+2C7rN27ayr86fuahm7qUeWocRdD8QUfrHUcjFsNbAYoCIkQ5 bJaItV+nbegWJQwENsDm81ql9ZtyfXqmZfsMYeMlTTpYyLPQ3X8wN1fkieSbHc7ORJ92 leSA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bt.com Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id t53si33185691qvc.91.2019.07.25.23.03.31 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Jul 2019 23:03:31 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bt.com Received: from localhost ([::1]:36392 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqtKE-0003a7-9r for alex.bennee@linaro.org; Fri, 26 Jul 2019 02:03:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51660) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqtK8-0003Yf-Ki for qemu-arm@nongnu.org; Fri, 26 Jul 2019 02:03:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hqtK6-0003Pr-Db for qemu-arm@nongnu.org; Fri, 26 Jul 2019 02:03:24 -0400 Received: from smtpe1.intersmtp.com ([213.121.35.71]:57753) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hqtJu-0002vb-Gx; Fri, 26 Jul 2019 02:03:10 -0400 Received: from tpw09926dag18e.domain1.systemhost.net (10.9.212.18) by BWP09926076.bt.com (10.36.82.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Fri, 26 Jul 2019 07:03:05 +0100 Received: from tpw09926dag18e.domain1.systemhost.net (10.9.212.18) by tpw09926dag18e.domain1.systemhost.net (10.9.212.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Jul 2019 07:03:05 +0100 Received: from tpw09926dag18e.domain1.systemhost.net ([fe80::a946:6348:ccf4:fa6c]) by tpw09926dag18e.domain1.systemhost.net ([fe80::a946:6348:ccf4:fa6c%12]) with mapi id 15.00.1395.000; Fri, 26 Jul 2019 07:03:05 +0100 From: To: , Thread-Topic: [Qemu-devel] [PATCH v4 02/15] memory: Access MemoryRegion with MemOp Thread-Index: AQHVQs6us5Ke12ptjEW1c49AzysqcKbbJooAgAE/RY4= Date: Fri, 26 Jul 2019 06:03:05 +0000 Message-ID: <1564120985317.14967@bt.com> References: <45d1ebe4b2ed4c039c9da20a738652df@tpw09926dag18e.domain1.systemhost.net> <1564048354001.54262@bt.com>, In-Reply-To: Accept-Language: en-AU, en-GB, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.42] Content-Type: multipart/alternative; boundary="_000_156412098531714967btcom_" MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 213.121.35.71 Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v4 02/15] memory: Access MemoryRegion with MemOp X-BeenThere: qemu-arm@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: peter.maydell@linaro.org, walling@linux.ibm.com, sagark@eecs.berkeley.edu, david@redhat.com, palmer@sifive.com, mark.cave-ayland@ilande.co.uk, Alistair.Francis@wdc.com, alex.williamson@redhat.com, arikalo@wavecomp.com, pasic@linux.ibm.com, borntraeger@de.ibm.com, rth@twiddle.net, atar4qemu@gmail.com, ehabkost@redhat.com, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, stefanha@redhat.com, shorne@gmail.com, david@gibson.dropbear.id.au, qemu-riscv@nongnu.org, kbastian@mail.uni-paderborn.de, cohuck@redhat.com, laurent@vivier.eu, qemu-ppc@nongnu.org, amarkovic@wavecomp.com, pbonzini@redhat.com, aurelien@aurel32.net Errors-To: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Sender: "Qemu-arm" X-TUID: HVprviAaT3RN --_000_156412098531714967btcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 7/25/19 9:45 PM, Philippe Mathieu-Daud=E9 wrote: >On 7/25/19 11:52 AM, tony.nguyen@bt.com wrote: >> Replacing size with size+sign+endianness (MemOp) will enable us to >> collapse the two byte swaps, adjust_endianness and handle_bswap, along >> the I/O path. >> >> While interfaces are converted, callers will have existing unsigned >> size coerced into a MemOp, and the callee will use this MemOp as an >> unsigned size. >> >> Signed-off-by: Tony Nguyen >> --- >> include/exec/memop.h | 4 ++++ >> include/exec/memory.h | 9 +++++---- >> memory.c | 7 +++++-- >> 3 files changed, 14 insertions(+), 6 deletions(-) >> >> diff --git a/include/exec/memop.h b/include/exec/memop.h >> index ac58066..09c8d20 100644 >> --- a/include/exec/memop.h >> +++ b/include/exec/memop.h >> @@ -106,4 +106,8 @@ typedef enum MemOp { >> MO_SSIZE =3D MO_SIZE | MO_SIGN, >> } MemOp; >> >> +/* No-op while memory_region_dispatch_[read|write] is converted to MemO= p */ >> +#define MEMOP_SIZE(op) (op) /* MemOp to size. */ >> +#define SIZE_MEMOP(ul) (ul) /* Size to MemOp. */ > >SIZE_MEMOP() is never used until patch #10 "memory: Access MemoryRegion >with MemOp semantics", it would be clearer to only introduce the >MEMOP_SIZE() no-op here, and directly introduce the correct SIZE_MEMOP() >macro in patch #10. SIZE_MEMOP() is used, and is the main change, in patches #3 to #10. Perhaps= you meant MEMOP_SIZE()? Either way, you have raised an issue :) There is a lack of clarity in how the two macros are used to update the interfaces.? --_000_156412098531714967btcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

On 7/25/19 9:45 PM, Philippe Mathieu-Daud=E9 wrote: 
>On 7/25/19 11:52 AM, tony.nguyen@bt.com wrote:
>> Replacing size with size+sign+endianness (MemOp) will= enable us to
>> collapse the two byte swaps, adjust_endianness and handle_bsw= ap, along
>> the I/O path.
>> 
>> While interfaces are converted, callers will have existing un= signed
>> size coerced into a MemOp, and the callee will use this MemOp= as an
>> unsigned size.
>> 
>> Signed-off-by: Tony Nguyen <tony.nguyen@bt.com>
>> ---
>>  include/exec/memop.h  | 4 ++++
>>  include/exec/memory.h | 9 +++++----=
>>  memory.c             &nbs= p;| 7 +++++--
>>  3 files changed, 14 insertions(+), 6 deletions(-)
>> 
>> diff --git a/include/exec/memop.h b/include/exec/memop.h
>> index ac58066..09c8d20 100644
>> --- a/include/exec/memop.h
>> +++ b/include/exec/memop.h
>> @@ -106,4 +106,8 @@ typedef enum MemOp {
>>      MO_SSIZE =3D MO_SIZE | MO_SIGN,
>>  } MemOp;
>> 
>> +/* No-op while memory_region_dispatch_[read|write] is co= nverted to MemOp */
>> +#define MEMOP_SIZE(op)  (op)    /* MemOp = to size.  */
>> +#define SIZE_MEMOP(ul)  (ul)    /* Size t= o MemOp.  */
>
>SIZE_MEMOP() is never used until patch #10 "memory: Access Me= moryRegion
>with MemOp semantics", it would be clearer to only introduce = the
>MEMOP_SIZE() no-op here, and directly introduce the correct SIZE_M= EMOP()
>macro in patch #10.

SIZE_MEMOP() is used, and is the main change, in patches #3 to #10. Pe= rhaps you
meant MEMOP_SIZE()?

Either way, you have raised an issue :)

There is a lack of clarity in how the two macros are used to update th= e
interfaces.​


--_000_156412098531714967btcom_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B8C5C7618B for ; Fri, 26 Jul 2019 06:03:47 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 31877206BA for ; Fri, 26 Jul 2019 06:03:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 31877206BA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bt.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36400 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqtKU-00045d-G9 for qemu-devel@archiver.kernel.org; Fri, 26 Jul 2019 02:03:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53246) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqtKI-0003hU-Bh for qemu-devel@nongnu.org; Fri, 26 Jul 2019 02:03:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hqtKG-000484-76 for qemu-devel@nongnu.org; Fri, 26 Jul 2019 02:03:34 -0400 Received: from smtpe1.intersmtp.com ([213.121.35.71]:57753) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hqtJu-0002vb-Gx; Fri, 26 Jul 2019 02:03:10 -0400 Received: from tpw09926dag18e.domain1.systemhost.net (10.9.212.18) by BWP09926076.bt.com (10.36.82.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Fri, 26 Jul 2019 07:03:05 +0100 Received: from tpw09926dag18e.domain1.systemhost.net (10.9.212.18) by tpw09926dag18e.domain1.systemhost.net (10.9.212.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Jul 2019 07:03:05 +0100 Received: from tpw09926dag18e.domain1.systemhost.net ([fe80::a946:6348:ccf4:fa6c]) by tpw09926dag18e.domain1.systemhost.net ([fe80::a946:6348:ccf4:fa6c%12]) with mapi id 15.00.1395.000; Fri, 26 Jul 2019 07:03:05 +0100 From: To: , Thread-Topic: [Qemu-devel] [PATCH v4 02/15] memory: Access MemoryRegion with MemOp Thread-Index: AQHVQs6us5Ke12ptjEW1c49AzysqcKbbJooAgAE/RY4= Date: Fri, 26 Jul 2019 06:03:05 +0000 Message-ID: <1564120985317.14967@bt.com> References: <45d1ebe4b2ed4c039c9da20a738652df@tpw09926dag18e.domain1.systemhost.net> <1564048354001.54262@bt.com>, In-Reply-To: Accept-Language: en-AU, en-GB, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.42] MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 213.121.35.71 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 Subject: Re: [Qemu-devel] [PATCH v4 02/15] memory: Access MemoryRegion with MemOp X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: peter.maydell@linaro.org, walling@linux.ibm.com, sagark@eecs.berkeley.edu, david@redhat.com, palmer@sifive.com, mark.cave-ayland@ilande.co.uk, Alistair.Francis@wdc.com, edgar.iglesias@gmail.com, alex.williamson@redhat.com, arikalo@wavecomp.com, pasic@linux.ibm.com, borntraeger@de.ibm.com, rth@twiddle.net, atar4qemu@gmail.com, ehabkost@redhat.com, qemu-s390x@nongnu.org, qemu-arm@nongnu.org, stefanha@redhat.com, shorne@gmail.com, david@gibson.dropbear.id.au, qemu-riscv@nongnu.org, kbastian@mail.uni-paderborn.de, cohuck@redhat.com, laurent@vivier.eu, qemu-ppc@nongnu.org, amarkovic@wavecomp.com, pbonzini@redhat.com, aurelien@aurel32.net Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 7/25/19 9:45 PM, Philippe Mathieu-Daud=E9 wrote: >On 7/25/19 11:52 AM, tony.nguyen@bt.com wrote: >> Replacing size with size+sign+endianness (MemOp) will enable us to >> collapse the two byte swaps, adjust_endianness and handle_bswap, along >> the I/O path. >> >> While interfaces are converted, callers will have existing unsigned >> size coerced into a MemOp, and the callee will use this MemOp as an >> unsigned size. >> >> Signed-off-by: Tony Nguyen >> --- >> include/exec/memop.h | 4 ++++ >> include/exec/memory.h | 9 +++++---- >> memory.c | 7 +++++-- >> 3 files changed, 14 insertions(+), 6 deletions(-) >> >> diff --git a/include/exec/memop.h b/include/exec/memop.h >> index ac58066..09c8d20 100644 >> --- a/include/exec/memop.h >> +++ b/include/exec/memop.h >> @@ -106,4 +106,8 @@ typedef enum MemOp { >> MO_SSIZE =3D MO_SIZE | MO_SIGN, >> } MemOp; >> >> +/* No-op while memory_region_dispatch_[read|write] is converted to MemO= p */ >> +#define MEMOP_SIZE(op) (op) /* MemOp to size. */ >> +#define SIZE_MEMOP(ul) (ul) /* Size to MemOp. */ > >SIZE_MEMOP() is never used until patch #10 "memory: Access MemoryRegion >with MemOp semantics", it would be clearer to only introduce the >MEMOP_SIZE() no-op here, and directly introduce the correct SIZE_MEMOP() >macro in patch #10. SIZE_MEMOP() is used, and is the main change, in patches #3 to #10. Perhaps= you meant MEMOP_SIZE()? Either way, you have raised an issue :) There is a lack of clarity in how the two macros are used to update the interfaces.?