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

[Alistair Francis]

On Wed, Dec 16, 2015 at 8:33 AM, Alistair Francis
<address@hidden> wrote:
> 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.

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