On 17/2/23 19:52, Thomas Huth wrote:
On 17/02/2023 15.18, Philippe Mathieu-Daudé wrote:
"hw/ptimer.h" API is mostly used by timer / watchdog device
models. Since the SoC / machines only access the ptimer via
reference, they don't need its definition: the declartion is
enough.
On order to reduce the inclusion on the source files,
forward-declare 'ptimer_state' in "qemu/typedefs.h".
Use the typedef in few place instead of the structure.
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
---
"30 files changed"... but since this is trivial, there is
no point in splitting per subsystem IMO.
---
...
diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index df4b55ac65..effcba4bca 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -104,6 +104,7 @@ typedef struct PICCommonState PICCommonState;
typedef struct PostcopyDiscardState PostcopyDiscardState;
typedef struct Property Property;
typedef struct PropertyInfo PropertyInfo;
+typedef struct ptimer_state ptimer_state;
Would it make sense to properly CamelCase the type while you're at it
anyway?
PeriodicTimer, PTimerState, PTimer?
This API is documented as 'ptimer API' although, and renaming all the
API methods doesn't seem to bring much, so maybe stick to PTimer.
More generically for QOM objects, we can agree for no 'State' trailing
for instance state, and 'Class' trailing for class one, similar to
Object / ObjectClass. I.e:
PeriodicTimer // instance
PeriodicTimerClass // class
Maybe 'Device' is too generic? Here the API uses 'qdev_' prefix, so
QDev / QDevClass could work...
