From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=45327 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q8tts-0006uT-6B
	for qemu-devel@nongnu.org; Sun, 10 Apr 2011 08:37:57 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <atar4qemu@gmail.com>) id 1Q8ttp-0001Fw-TI
	for qemu-devel@nongnu.org; Sun, 10 Apr 2011 08:37:55 -0400
Received: from mail-qw0-f45.google.com ([209.85.216.45]:44745)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <atar4qemu@gmail.com>) id 1Q8ttp-0001Fh-QA
	for qemu-devel@nongnu.org; Sun, 10 Apr 2011 08:37:53 -0400
Received: by qwj8 with SMTP id 8so3356209qwj.4
	for <qemu-devel@nongnu.org>; Sun, 10 Apr 2011 05:37:53 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <1301170017-12368-1-git-send-email-weil@mail.berlios.de>
References: <1301170017-12368-1-git-send-email-weil@mail.berlios.de>
From: Artyom Tarasenko <atar4qemu@gmail.com>
Date: Sun, 10 Apr 2011 14:37:32 +0200
Message-ID: <BANLkTinfWZJNQFGsmU96RrkLqZ30D5pb-w@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH 1/3] cpu-common: Modify
	cpu_physical_memory_read and cpu_physical_memory_write
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Weil <weil@mail.berlios.de>
Cc: Blue Swirl <blauwirbel@gmail.com>, QEMU Developers <qemu-devel@nongnu.org>

On Sat, Mar 26, 2011 at 9:06 PM, Stefan Weil <weil@mail.berlios.de> wrote:
> A lot of calls don't operate on bytes but on words or on structured data.
> So instead of a pointer to uint8_t, a void pointer is the better choice.

Wouldn't it make the endianness conversions more complex? uint8_t[]
has a very obvious byte order,
structured data doesn't.

> This allows removing many type casts.
>
> (Some very early implementations of memcpy used char pointers
> which were replaced by void pointers for the same reason).
>
> Cc: Blue Swirl <blauwirbel@gmail.com>
> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
> ---
> =A0cpu-common.h | =A0 =A04 ++--
> =A01 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cpu-common.h b/cpu-common.h
> index ef4e8da..f44a2b0 100644
> --- a/cpu-common.h
> +++ b/cpu-common.h
> @@ -68,12 +68,12 @@ void cpu_unregister_io_memory(int table_address);
> =A0void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int len, int is_w=
rite);
> =A0static inline void cpu_physical_memory_read(target_phys_addr_t addr,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0uint8_t *buf, int len)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0void *buf, int len)
> =A0{
> =A0 =A0 cpu_physical_memory_rw(addr, buf, len, 0);
> =A0}
> =A0static inline void cpu_physical_memory_write(target_phys_addr_t addr,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 const uint8_t *buf, int len)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 const void *buf, int len)
> =A0{
> =A0 =A0 cpu_physical_memory_rw(addr, (uint8_t *)buf, len, 1);
> =A0}
> --
> 1.7.2.5
>
>
>



--=20
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/