From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8waR-0008KK-H9 for qemu-devel@nongnu.org; Tue, 15 Dec 2015 15:52:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8waQ-0000kY-ET for qemu-devel@nongnu.org; Tue, 15 Dec 2015 15:52:43 -0500 Received: from mail-wm0-x231.google.com ([2a00:1450:400c:c09::231]:38013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8waQ-0000kU-8W for qemu-devel@nongnu.org; Tue, 15 Dec 2015 15:52:42 -0500 Received: by mail-wm0-x231.google.com with SMTP id l126so11296028wml.1 for ; Tue, 15 Dec 2015 12:52:41 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 15 Dec 2015 12:52:41 -0800 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v1 00/15] data-driven device registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Edgar Iglesias , Edgar Iglesias , "qemu-devel@nongnu.org Developers" , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Alistair Francis On Tue, Dec 15, 2015 at 11:46 AM, Peter Maydell wrote: > On 30 October 2015 at 08:06, Peter Maydell wrote: >> On 30 October 2015 at 06:52, Peter Crosthwaite >> wrote: >>> Ping^3 >>> >>> This has been on list for a very long time without 3rd party review. >>> Can I send a PULL? >> >> I would prefer not to take a new unreviewed feature >> in softfreeze for 2.5... > > Since we're now about to come out of 2.5 freeze I guess I > should write something about this patchset. I don't have any > fundamental objections to it, but it doesn't really excite me > either. I would like to see it reviewed by somebody else who > does think it's a good idea, because I think that increases > the chances that we will get general use of the facilities > rather than it being an odd thing used by a few Xilinx device > models and nothing else. > It needs to exist before it can be used so there is a bit of a chicken and egg problem there. It is originally my code and Alistair has taken ownership of it so that excludes the both of us. Aside from yourself, there aren't too many new device-model authors out there who are active review. Do you have a nominee? It is a developer-centric feature as you can do things like gen device model templates from data. The philosophy here (which is contrary to most maintainers thinking) is that hardware designers and people who constantly change hardware design specs and create new bits of IP are the consumer of QEMU and the QEMU source code is a consumable. So I see why it is hard to excite your regular QEMU developer who is thinking purely about non-engineering end consumers. I'll throw a new argument into the mix that is closer to home for yourself, it has a lot in common with the ARM CP API. If we converted the ARM CP API to be data driven rather than code driven (which we have), why are MMIO devices so different? CP accesses can be side-effectless or require side-effect causing functions, and 99% of sysbus devices fit this description. Ideally, I'd like to mass-covert CP API to use something like this for one API to rule them all. If I instead morphed the CP API to a generic feature in hw/core, extended with the features of this patch set, would that work better for you? Then both devices and custom register APIs (like CP) can be standardised. Note that this is already two layered. The concept of the register API which defines collections of registers is separate from sysbus. Regards, Peter > I hope that makes sense and doesn't seem too arbitrary a > hurdle to make you jump? > > thanks > -- PMM