From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9yYZ-00055X-9I for qemu-devel@nongnu.org; Wed, 23 Jul 2014 11:34:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X9yYS-00072z-O8 for qemu-devel@nongnu.org; Wed, 23 Jul 2014 11:34:15 -0400 Received: from mail-we0-f182.google.com ([74.125.82.182]:50912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9yYS-00072r-IA for qemu-devel@nongnu.org; Wed, 23 Jul 2014 11:34:08 -0400 Received: by mail-we0-f182.google.com with SMTP id k48so1366984wev.13 for ; Wed, 23 Jul 2014 08:34:05 -0700 (PDT) Message-ID: <53CFD5D2.4090602@linaro.org> Date: Wed, 23 Jul 2014 17:33:38 +0200 From: Eric Auger MIME-Version: 1.0 References: <1404716892-15600-1-git-send-email-eric.auger@linaro.org> <1404716892-15600-6-git-send-email-eric.auger@linaro.org> <53BBF781.9070102@suse.de> In-Reply-To: <53BBF781.9070102@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/7] hw/core/sysbus: add fdt_add_node method List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , eric.auger@st.com, christoffer.dall@linaro.org, qemu-devel@nongnu.org, kim.phillips@freescale.com, a.rigo@virtualopensystems.com Cc: peter.maydell@linaro.org, patches@linaro.org, stuart.yoder@freescale.com, alex.williamson@redhat.com, a.motakis@virtualopensystems.com, kvmarm@lists.cs.columbia.edu On 07/08/2014 03:52 PM, Alexander Graf wrote: > > On 07.07.14 09:08, Eric Auger wrote: >> This method is meant to be called on sysbus device dynamic >> instantiation (-device option). Devices that support this >> kind of instantiation must implement this method. >> >> Signed-off-by: Eric Auger > > For the reason I stated earlier, I don't think it's a good idea to put > device tree code into our device models. Hi Alex, I would propose we discuss that topic during next KVM call if you are available. Hope Peter will be available to join too. Because I feel stuck between not putting things in the machine file (1) - obviously we could put them in a helper module (2) - and not putting them in the device (3). Whatever the solution I fear we are going to pollute something: Any time a new device wants to support dynamic instantiation, we would need to modify the machine file or the helper module with 1 and 2 resp. In case we put it in the device we pollute this latter... My hope was that quite few QEMU platform devices would need to support that feature and hence would need to implement this dt node generation method. To me dynamic instantiation of platform device was not the mainstream solution. Then there is the fundamental question of technical feasibility of devising a generic PlatformParams that match all the specialization needs? Here I miss experience. In case we know the machine type and a small set of additional fields couldn't we do the adaptations you talked about, related to IRQs? Best Regards Eric > > > Alex >