Re: [PATCH 1/6] hw/arm: Inline sysbus_create_simple(PL110 / PL111)

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 19/2/24 14:33, Mark Cave-Ayland wrote:
> On 19/02/2024 13:05, Peter Maydell wrote:
> 
>> On Mon, 19 Feb 2024 at 12:49, Mark Cave-Ayland
>> <mark.cave-ayland@ilande.co.uk> wrote:
>>>
>>> On 19/02/2024 12:00, BALATON Zoltan wrote:
>>>> For new people trying to contribute to QEMU QDev is overwhelming so 
>>>> having some way
>>>> to need less of it to do simple things would help them to get started.
>>>
>>> It depends what how you define "simple": for QEMU developers most 
>>> people search for
>>> similar examples in the codebase and copy/paste them. I'd much rather 
>>> have a slightly
>>> longer, but consistent API for setting properties rather than coming 
>>> up with many
>>> special case wrappers that need to be maintained just to keep the 
>>> line count down for
>>> "simplicity".
>>>
>>> I think that Phil's approach here is the best one for now, 
>>> particularly given that it
>>> allows us to take another step towards heterogeneous machines. As the 
>>> work in this
>>> area matures it might be that we can consider other approaches, but 
>>> that's not a
>>> decision that can be made right now and so shouldn't be a reason to 
>>> block this change.
>>
>> Mmm. It's unfortunate that we're working with C, so we're a bit limited
>> in what tools we have to try to make a better and lower-boilerplate
>> interface for the "create, configure, realize and wire up devices" task.
>> (I think you could do much better in a higher level language...)
>> sysbus_create_simple() was handy at the time, but it doesn't work so
>> well for more complicated SoC-based boards. It's noticeable that
>> if you look at the code that uses it, it's almost entirely the older
>> and less maintained board models, especially those which don't actually
>> model an SoC and just have the board code create all the devices.
> 
> Yeah I was thinking that you'd use the DSL (e.g. YAML templates or 
> similar) to provide some of the boilerplating around common actions, 
> rather than the C API itself. Even better, once everything has been 
> moved to use a DSL then the C API shouldn't really matter so much as it 
> is no longer directly exposed to the user.

Something similar was discussed with Markus and Manos. Although the
first step we noticed is to unify the QDev API -- making it verbose --
to figure what we need to expose in the DSL. Doing it the other way
(starting a DSL and trying to adapt it to all QEMU models) seemed a
waste of time. At least for our current human resources.