On Tue, Oct 18, 2016 at 10:08:21PM +0100, Peter Maydell wrote:
> On 18 October 2016 at 21:49, Eduardo Habkost <ehabk...@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
