From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr54o-00038g-Ev for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:18:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr54k-0002SY-CK for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:18:14 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:44615) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr54k-0002Ro-7F for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:18:10 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NWV006DCUE7L940@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Tue, 27 Oct 2015 14:18:07 +0000 (GMT) From: Pavel Fedin References: <00f601d10fc2$7673fd00$635bf700$@samsung.com> <013701d110af$5f601a70$1e204f50$@samsung.com> In-reply-to: Date: Tue, 27 Oct 2015 17:18:06 +0300 Message-id: <002f01d110c2$4cd51d70$e67f5850$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Content-language: ru Subject: Re: [Qemu-devel] [PATCH v2] target-arm: Extract some external ARM CPU API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Peter Maydell' Cc: 'Shlomo Pongratz' , 'Peter Crosthwaite' , 'QEMU Developers' , 'Shlomo Pongratz' Hello! > But Peter C has a better grasp of the current status of > multiarch than I do, so if he prefers using obj-y then > I'm happy to take his recommendation. I am neutral, and i will accept any solution. OTOH, he agreed with my = proposal too, and even promised to pick it up into his patchsets, but = suggested to change include pathname to include/hw/arm/cpu.h. And i have = the last concern about it because hw/arm/ is a place where = board-specific includes are placed. Additionally, we already have three more specific ARM CPU files in = include/hw/cpu/, so they just look nice together. And you know... Theoretically... As far as i can understand, multi-arch = is a way to enable emulation of heterogeneous systems, which combine = different CPUs. Am i right about it? In this case, what if in future we = have some heterogeneous HW, where e.g. ARM and x86 are interoperating = using system registers? In this case, x86-targeted qemu code would = probably have to talk to ARM-targeted one. And having this API separated = from the inner CPU guts would only help. Compared to this architectural improvement, obj-y looks like very = simple way to ignore, but not to solve the problem. :) So, Peter C, what is your final decision? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia