On Wed, Dec 16, 2015 at 8:33 AM, Alistair Francis <alistair.fran...@xilinx.com> wrote: > 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.
No one seems to be jumping at reviewing this. Can we just send a pull request? Thanks, Alistair >> >> 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 >>
