From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IsNhO-0005KQ-UX
	for qemu-devel@nongnu.org; Wed, 14 Nov 2007 14:14:54 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IsNhO-0005JJ-DY
	for qemu-devel@nongnu.org; Wed, 14 Nov 2007 14:14:54 -0500
Received: from mx1.polytechnique.org ([129.104.30.34])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <fabrice@bellard.org>) id 1IsNhL-000132-Og
	for qemu-devel@nongnu.org; Wed, 14 Nov 2007 14:14:52 -0500
Message-ID: <473B4928.9030607@bellard.org>
Date: Wed, 14 Nov 2007 20:14:48 +0100
From: Fabrice Bellard <fabrice@bellard.org>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] target_posix_types.h
References: <1195055987.918.34.camel@phantasm.home.enterpriseandprosperity.com>	
	<473B3F3E.5020107@bellard.org>
	<1195065836.918.61.camel@phantasm.home.enterpriseandprosperity.com>
In-Reply-To: <1195065836.918.61.camel@phantasm.home.enterpriseandprosperity.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: thayne@c2.net
Cc: qemu-devel@nongnu.org

Thayne Harbaugh wrote:
> On Wed, 2007-11-14 at 19:32 +0100, Fabrice Bellard wrote:
>> Thayne Harbaugh wrote:
>>> This patch, 44_target_posix_types.patch provides target specific posix
>>> types.  These types improve target structure creation, code similarity
>>> to kernel code and improve type casting for assignment between target
>>> and host.
>> Why is it needed ?
> 
> 
> It's not *necessary*, but it makes code more readable and it simplifies
> having to always check for what a typedef on a target might map to.  It
> makes target structures more comparable to their structures in the
> kernel.
> 
> A simple example:
> 
> struct target_timeval {
>     abi_long tv_sec;
>     abi_long tv_usec;
> };
> 
> vs.
> 
> struct target_timeval {
>     target_time_t tv_sec;
>     target_suseconds_t tv_usec;
> };
> 
> 
> It also makes type conversion between target and host more obvious.
> 
> It also means that more code can be shared rather than #ifdef'ed when
> targets differ on their base definitions.
> 
> It's just another level of abstraction, we can always stick with
> abi_long, abi_ulong, etc..  I've just noticed that size and sign
> handling when converting between target and host are a common source of
> errors and this simplifies things.  We use it in all our patches and it
> has helped simplify and fix errors.

I don't like adding levels of abstraction unless I am really forced. I 
think these types makes the code more difficult to understand without 
real added value. In particular, it does not help for sign conversions.

Fabrice.