________________________________________
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
