Re: [Qemu-arm] QOM properties vs C functions/fields (was Re: [Qemu-devel] [PATCH v3 2/3] exec: rename cpu_exec_init() as cpu_exec_realizefn())

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Oct 18, 2016 at 10:08:21PM +0100, Peter Maydell wrote:
> On 18 October 2016 at 21:49, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > On Tue, Oct 18, 2016 at 09:30:01PM +0100, Peter Maydell wrote:
> >> Lots of stuff in a device's C struct is strictly internal
> >> and not to be messed with. I thought that QOM properties
> >> were essentially how a device defined its public (and
> >> typically settable-only-once) config knobs. QOM properties
> >> shouldn't be user-facing (read: stable, required to be
> >> backwards-compatible) interface in general because
> >> we don't really want to tie ourselves down that much.
> >> In fact almost all our QOM objects are not usefully
> >> user-facing at all.
> >
> > This interpretation surprises me, because it is the opposite of
> > what I have seen us doing. Most of our QOM objects and properties
> > are user-visible and user-configurable using -global, -device,
> > -object, or qom-set (and probably other QMP commands).
> 
> Most of the devices I deal with are not and never will
> be sensibly usable with -device. Exposing wiring up
> of IRQ and GPIO lines or MMIO regions to the user is
> never going to make sense. For x86 most devices are
> probably pluggable (and usable with -device), but over
> the whole source tree I think the embedded-style device
> is in the majority. They're all still worth QOMifying
> and having properties for the things board code wants
> to modify, though.

Even if they are not usable with -device, all properties are
configurable using -global. There's no mechanism to avoid letting
the user configure properties for devices. Is this really OK?

If internal-only usage is also an intended use case for QOM
properties, fine. But I believe we need to communicate this more
clearly, based on the previous thread (subject: "QOM: best way
for parents to pass information to children?").

BTW, if most devices aren't supposed to be used with -device,
possibly many of them don't have
cannot_instantiate_with_device_add_yet set properly. On the 2.6.2
binaries in Fedora 24, I see:

* 1671 device types (including CPU types)
* 1011 CPU device types
* 1076 no-user device types (including CPU types)
* 660 non-CPU device types
* 65 no-user non-CPU device types (10% of them)
* 860 type_register_*() lines in the code
  (this includes non-TYPE_DEVICE types, though)
* 56 cannot_instantiate_with_device_add_yet=true lines in the code

Commands I used to get the numbers above:

  $ for f in /usr/bin/qemu-system-*;do \
     (echo 'info qdm';echo quit;) | $f -machine none -nodefaults -monitor stdio -nographic 2>&1 \
    done | grep ^name | sort -u > /tmp/devs
  $ wc -l /tmp/devs
  1671 /tmp/devs
  $ grep no-user /tmp/devs | wc -l
  1076
  $ grep -- '-cpu"' /tmp/devs | wc -l
  1011
  $ grep -v -- '-cpu"' /tmp/devs | wc -l
  660
  $ grep -v -- '-cpu"' /tmp/devs | grep no-user | wc -l
  65
  $ 

-- 
Eduardo