qemu-arm
[Top][All Lists]
Advanced

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

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


From: Mark Cave-Ayland
Subject: Re: [PATCH 1/6] hw/arm: Inline sysbus_create_simple(PL110 / PL111)
Date: Wed, 21 Feb 2024 10:40:29 +0000
User-agent: Mozilla Thunderbird

On 19/02/2024 13:35, Peter Maydell wrote:

On Mon, 19 Feb 2024 at 13:33, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> 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.

That does feel like it's rather a long way away, though, so there
might be scope for improving our C APIs in the meantime. (Also,
doing the boilerplating with fragments of YAML or whatever means
that checking of eg typos and other syntax errors shifts from
compile time to runtime, which is a shame.)

I think most people who frequently use QOM/qdev have ideas as to how to improve the C API, but what seems clear to me is that the analysis of scenarios by Phil, Markus and others as part of the heterogeneous machine work is useful and should be used to help guide future work in this area.

If there are proposed changes in the C API, I'd be keen to see a short RFC detailing the changes and their rationale to aid developers/reviewers before they are introduced into the codebase.


ATB,

Mark.



reply via email to

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