Re: [Qemu-devel] [PATCH v1 00/15] data-driven device registers

[Peter Maydell]

On 15 December 2015 at 20:52, Peter Crosthwaite
<address@hidden> 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