qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 19/26] rust: rename qemu-api modules to follow C code a bit m


From: Zhao Liu
Subject: Re: [PATCH 19/26] rust: rename qemu-api modules to follow C code a bit more
Date: Fri, 13 Dec 2024 17:19:50 +0800

> > In this commit, this comment is a bit ahead, but I think it's okay.
> > 
> > qom and qdev are both good names. In addition, we can rename the files
> > of PL011 as well. Perhaps device_class.rs could be merged into device.rs
> > (and eventually renamed to pl011.rs). I guess you might be planning to
> > keep it until the cleanup of vmstate and property is done.
> 
> Yeah, I don't have any specific plans but memory_ops will certainly go away.

This depends on MemoryRegionOps binding. I will see how much HPET can do,
and I'm sorry for not being able to review the remaining patches yet in
this week, especially the last two. I will continue next week (my machine
will be powered down until next Monday :( ).

> device_class doesn't do much, but keeping it separate is a reminder for
> things that are still there to be cleaned up.
> 
> As to VMState, there are two parts.  One is the vmstate_description macro,
> probably it has to be replaced with something else to incorporate the
> trampolines for pre_save/post_load/...  I haven't looked at it but it should
> not be a lot of work.
> 
> The second is VMStateFields, 

I found vmstate_array_of_pointer_to_struct missed a `info` field, and I
could submit a patch to fix this nit next week (along with other cleanup
you and other miantainers suggested for HPET).

I'd also like to try apply zeroable to VMStateField to avoid missing any
items...

> for which my idea is to implement a trait on
> types to retrieve a basic VMStateField (for example something like
> vmstate_uint32 would become an implementation of the VMState trait on u32).

This makes sense.

> Then you'd write something like "vmstate_of!(Type,
> field).with_version_id(2)" (i.e. vmstate_of retrieves the basic field and
> fills in the offset, then you apply more changes on top).  But that may take
> a while, and I think it cannot be done without the const_refs_to_static
> feature, which is only stable in 1.83.0.

I also like this idea!

Thanks,
Zhao





reply via email to

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