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

[Peter Crosthwaite <crosthwaitepeter@gmail.com>]

On Tue, Dec 15, 2015 at 11:46 AM, Peter Maydell
<peter.maydell@linaro.org> wrote:
> On 30 October 2015 at 08:06, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 30 October 2015 at 06:52, Peter Crosthwaite
>> <crosthwaitepeter@gmail.com> wrote:
>>> Ping^3
>>>
>>> This has been on list for a very long time without 3rd party review.
>>> Can I send a PULL?
>>
>> I would prefer not to take a new unreviewed feature
>> in softfreeze for 2.5...
>
> Since we're now about to come out of 2.5 freeze I guess I
> should write something about this patchset. I don't have any
> fundamental objections to it, but it doesn't really excite me
> either. I would like to see it reviewed by somebody else who
> does think it's a good idea, because I think that increases
> the chances that we will get general use of the facilities
> rather than it being an odd thing used by a few Xilinx device
> models and nothing else.
>

It needs to exist before it can be used so there is a bit of a chicken
and egg problem there. 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?

It is a developer-centric feature as you can do things like gen device
model templates from data. The philosophy here (which is contrary to
most maintainers thinking) is that hardware designers and people who
constantly change hardware design specs and create new bits of IP are
the consumer of QEMU and the QEMU source code is a consumable. So I
see why it is hard to excite your regular QEMU developer who is
thinking purely about non-engineering end consumers.

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.

Regards,
Peter

> I hope that makes sense and doesn't seem too arbitrary a
> hurdle to make you jump?
>
> thanks
> -- PMM