qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alistair Francis
Subject: Re: [Qemu-devel] [PATCH v1 00/15] data-driven device registers
Date: Wed, 16 Dec 2015 08:33:39 -0800

On Tue, Dec 15, 2015 at 1:56 PM, Peter Maydell <address@hidden> wrote:
> 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).

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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]