From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:32959)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kbastian@mail.uni-paderborn.de>) id 1X5Xfs-0007rj-H3
	for qemu-devel@nongnu.org; Fri, 11 Jul 2014 06:03:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kbastian@mail.uni-paderborn.de>) id 1X5Xfk-0000RP-L0
	for qemu-devel@nongnu.org; Fri, 11 Jul 2014 06:03:28 -0400
Received: from mail.uni-paderborn.de ([131.234.142.9]:19928)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kbastian@mail.uni-paderborn.de>) id 1X5Xfk-0000Nv-EL
	for qemu-devel@nongnu.org; Fri, 11 Jul 2014 06:03:20 -0400
Message-ID: <53BFC50C.8010803@mail.uni-paderborn.de>
Date: Fri, 11 Jul 2014 12:05:48 +0100
From: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
MIME-Version: 1.0
References: <1404756822-3253-1-git-send-email-kbastian@mail.uni-paderborn.de>
	<1404756822-3253-2-git-send-email-kbastian@mail.uni-paderborn.de>
	<CAFEAcA_YnUF8f2JymPFCvrr2kJqNf5u=Do5Xo3M-h2cvn9zumg@mail.gmail.com>
In-Reply-To: <CAFEAcA_YnUF8f2JymPFCvrr2kJqNf5u=Do5Xo3M-h2cvn9zumg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 01/15] target-tricore: Add target stubs and
	qom-cpu
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>, Richard Henderson <rth@twiddle.net>

Hi Peter,

On 07/07/2014 08:24 PM, Peter Maydell wrote:
> I think you probably want the configure and default-configs changes to 
> be at the end of the patch series (or at least part way through it), 
> not at the start. The general approach is: * some patches which 
> implement the basic absolute minimum functionality, usefully split up 
> * then add the configure and default-configs changes that allow the 
> user to select the target and include it in the default target list
Would you recommend to add the part, which activates the target, at the 
end of this patch series or at the end of the implementation of the target?

thanks,

Bastian