On 07/07/2026 15:19, Peter Maydell wrote:
On Tue, 7 Jul 2026 at 14:08, Mark Cave-Ayland
<[email protected]> wrote:
On 07/07/2026 13:05, Daniel P. Berrangé wrote:
On Fri, Jul 03, 2026 at 02:53:03PM +0100, Mark Cave-Ayland wrote:
I wonder why "line_size" isn't merely a field in the machine class ?
External code ought to be able to fetch the current machine and read
a line_size struct field, surely ?
It certainly looks odd from here: one of things I wanted to discuss on
the call was how to approach the conversion.
My current thinking is that the aim should be simply to convert
everything as-is, and avoid attempting any refactorings or converting to
a device class prop via device_class_set_props() if possible.
Oh yeah, I was going to ask how device_class_set_props() fits in here.
That is a much nicer API for the cases where it fits. I would like
any QOM-level API for setting up class properties to be as easy
and convenient to use as that is for the basic "there is a property
and it just sets a field in the object structure" common case.
(Obviously the more oddball stuff will need finer control.)
Having a look at these series, I think we can come up with some basic
rules as to whether an object property could be promoted to a static
Property:
- The QOM object in question must inherit from TYPE_DEVICE
- The getter and setter must only set/retrieve the value with no
additional logic/constraints included
- The object property in question must not be a QOM array element i.e.
a name of the form "foo[N]"
- The object property must be declared with OBJ_PROP_FLAG_READWRITE
- The object property must be defined directly in an QOM init()
function, or a static function called from it
Does that seem reasonable?
ATB,
Mark.
