________________________________________ From: Philippe Mathieu-Daudé <phi...@redhat.com> Sent: Friday, July 26, 2019 1:03 PM To: tony.ngu...@bt.com; qemu-devel@nongnu.org Cc: peter.mayd...@linaro.org; wall...@linux.ibm.com; sag...@eecs.berkeley.edu; m...@redhat.com; pal...@sifive.com; mark.cave-ayl...@ilande.co.uk; laur...@vivier.eu; alistair.fran...@wdc.com; edgar.igles...@gmail.com; Aleksandar Rikalo; da...@redhat.com; pa...@linux.ibm.com; borntrae...@de.ibm.com; r...@twiddle.net; atar4q...@gmail.com; ehabk...@redhat.com; qemu-s3...@nongnu.org; qemu-...@nongnu.org; stefa...@redhat.com; sho...@gmail.com; da...@gibson.dropbear.id.au; qemu-ri...@nongnu.org; kbast...@mail.uni-paderborn.de; coh...@redhat.com; alex.william...@redhat.com; qemu-...@nongnu.org; Aleksandar Markovic; pbonz...@redhat.com; aurel...@aurel32.net Subject: [EXTERNAL]Re: [Qemu-devel] [PATCH v5 09/15] cputlb: Access MemoryRegion with MemOp
On 7/26/19 8:46 AM, tony.ngu...@bt.com wrote: > No-op MEMOP_SIZE and SIZE_MEMOP macros allows us to later easily > convert memory_region_dispatch_{read|write} paramter "unsigned size" > into a size+sign+endianness encoded "MemOp op". > > Being a no-op macro, this patch does not introduce any logical change. > The last sentence has a bad structure. Possible remedy: "Being a no-op macro," -> "Relying no-op macros," I think this patch should be reogranized (possibly by splitting) so that the hunks that introduce usage of macros are in a separate patch, which would leave only changes that directly involve using "MemOp" in this patch. Thanks, Aleksandar