On 26.04.2018 13:54, Markus Armbruster wrote: > Thomas Huth <th...@redhat.com> writes: [...] > Actually, a worse offender in the "waste everybody's time via redunancy" > department could be qom-test.
I guess we could also change the logic in qom-tester to only run with all machines if we're in SPEED=slow mode, and rather only use the "none" machine by default? >> Anyway, do you think my patch here is useful and has a chance of getting >> included? I.e. shall I re-spin this as a non-RFC patch? Or shall we >> rather wait for Eduardo's python-based tests to get included into the >> repository? > > I don't mind having make check SPEED=slow run more extensive tests. > Assuming we actually run them at least once in a while, which seems > doubtful. If some developers (like myself) are running it at least every couple of weeks manually, that's already much better than nothing! >>>> Signed-off-by: Thomas Huth <th...@redhat.com> >>>> --- >>>> In case someone wants to help with creating some bug fix patches >>>> during the QEMU hard freeze phase: This test can now be used to >>>> trigger lots of introspection bugs that we were not aware of yet. >>>> I think most of the bugs are due to wrong handling of instance_init >>>> vs. realize functions. >>> >>> Yes, that's a common class of bugs. There's little guidance on what >>> kind of work belongs where, and plenty of bad examples. >> >> I think we urgently need a file in doc/devel/ that describes the various >> states / functions of a device, where we should properly describe the >> differences between instance_init and realize. ... I'll try to come up >> with something when I've got some spare time (unless somebody else >> volunteers to do that first). > > Please do. > > Widen the scope from just TYPE_DEVICE to all of QOM? I don't have that much experience with QOM yet that I'd dare to write a doc about it. Would you maybe be interested in writing something up about QOM? Thomas
