From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9F1n-0008O8-3j for qemu-devel@nongnu.org; Wed, 16 Dec 2015 11:34:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9F1l-0000Z1-UN for qemu-devel@nongnu.org; Wed, 16 Dec 2015 11:34:11 -0500 Received: from mail-ob0-x232.google.com ([2607:f8b0:4003:c01::232]:33532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9F1l-0000Yw-Q0 for qemu-devel@nongnu.org; Wed, 16 Dec 2015 11:34:09 -0500 Received: by mail-ob0-x232.google.com with SMTP id sd4so36846603obb.0 for ; Wed, 16 Dec 2015 08:34:09 -0800 (PST) MIME-Version: 1.0 Sender: alistair23@gmail.com In-Reply-To: References: From: Alistair Francis Date: Wed, 16 Dec 2015 08:33:39 -0800 Message-ID: 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 , "qemu-devel@nongnu.org Developers" , Alistair Francis , Peter Crosthwaite , Edgar Iglesias , =?UTF-8?Q?Andreas_F=C3=A4rber?= On Tue, Dec 15, 2015 at 1:56 PM, Peter Maydell wrote: > On 15 December 2015 at 20:52, Peter Crosthwaite > wrote: >> It needs to exist before it can be used so there is a bit of a chicken >> and egg problem there. > > Right, but the hope would be that there's somebody who cares > about device models who thinks it's worthwhile... if we really > do only have three people who write devices then that's a bit sad. > >> 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? > > For instance, do any of the MIPS, PPC or SPARC maintainers see > it as useful for their devices? > >> 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. > > The coprocessor APIs are data driven because we had the previous > lots-of-switch-statements approach and it was terrible to > maintain. On the other hand I look at the average device > (say hw/misc/a9scu.c or hw/misc/arm_sysctl.c) and it doesn't > really seem that hard to deal with (in particular you only > have one level of switching, on the register address, rather > than four levels with opc1/opc2/crn/crm, and your average > device has tens of registers rather than hundreds). I think this problem is only going to get worse though. Look at the ARM SMMU implementation which we have, it has hundreds of registers (https://github.com/Xilinx/qemu/blob/master/hw/misc/arm-smmu.c). Admittedly it is still only one level of switch statements, but devices are only getting more complex. Thanks, Alistair > > Basically, the cp API change was a bit of an upheaval but > clearly worthwhile because we were feeling the pain of not > having it. I'm not convinced we're feeling that much pain from > our current approach to device registers, and I'm definitely > not convinced that we'd make a wholesale conversion to use > this new API the way we did with the cp API. > > As I say, I don't fundamentally object to this, but I'd be > happier if you convinced some other developer of the utility... > > thanks > -- PMM >