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). 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
