Re: [Question] What is the definition of “private” fields in QOM?

[Zhao Liu <zhao1.liu@intel.com>]

On Mon, Oct 21, 2024 at 04:06:08PM +0100, Peter Maydell wrote:
> Date: Mon, 21 Oct 2024 16:06:08 +0100
> From: Peter Maydell <peter.maydell@linaro.org>
> Subject: Re: [Question] What is the definition of “private” fields in
>  QOM?
> 
> On Mon, 21 Oct 2024 at 16:02, Zhao Liu <zhao1.liu@intel.com> wrote:
> >
> > On Mon, Oct 21, 2024 at 03:20:39PM +0100, Peter Maydell wrote:
> > > What I mean by "the private/public markers are unnecessary" is
> > > that they don't tell the reader anything, because all the fields
> > > in a QOM device struct are private.
> >
> > This time I really understand the question of whether it's okay to
> > directly access parent_obj/parent_class. :-)
> >
> > > If you're not in the implementation of that class, then you shouldn't
> > > really be directly touching any of the fields in the state struct.
> > > (In some places we take a shortcut and do it. But really it's almost
> > > never necessary.)
> >
> > Thank you for your further explanation! I hadn’t noticed that. So, for
> > other code (code outside the class/object implementation) to access the
> > fields other than parent_obj/parent_class of class/state struct, the
> > most ideal way would be to use the set/get property interfaces as
> > much as possible instead of accessing them directly, right?
> 
> Yes, or whatever APIs (functions etc) are provided for working
> with the class. If you have a specific example we could probably
> make some more concrete suggestions.

My initial confusion stemmed from seeing the private comment and
noticing that there are many direct accesses to parent_obj/parent_class
in QEMU (which I could list in my reply to Daniel). Now I understand
that these examples are only valid within the class/object
implementation or in QOM code.

For instance, an example in KVM is a misuse:

accel/kvm/kvm-all.c:4285:                        cpu->parent_obj.canonical_path,
accel/kvm/kvm-all.c:4377:            if (!apply_str_list_filter(cpu->parent_obj.canonical_path, targets)) {


At the same time, I’ve been thinking that the current C implementation
seems to have no way to prevent such misuse. So for Rust's class/state,
should parent_class/parent_obj also be defined as private (for example,
by removing the pub keyword from PL011State in rust/hw/char/pl011/src/
device.rs)?

However, through our discussion, I realized that in QOM, "private" does
not only refer to parent_obj/parent_class, but all fields belong to
this category. If everything is strictly defined as private in Rust, it
seems impractical…

Thanks,
Zhao