On Tue, Dec 15, 2015 at 1:56 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 15 December 2015 at 20:52, Peter Crosthwaite > <crosthwaitepe...@gmail.com> 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 >
