Am 25.04.2014 08:38, schrieb Markus Armbruster: > Andreas Färber <afaer...@suse.de> writes: > >> Am 24.04.2014 08:19, schrieb Jan Kiszka: >>> On 2014-04-23 11:25, Stefan Hajnoczi wrote: >>>> Dear QEMU, Libvirt, and KVM communities, We are participating in >>>> Google Summer of Code 2014 (http://google-melange.com/) and >>>> Outreach Program for Women (http://opw.gnome.org/). Both >>>> programs fund candidates to work on our open source projects for >>>> 12 weeks this summer. >>> >>> To follow up on this: I'm currently looking for optional tiny >>> "warmup" tasks for our QEMU students during the bonding period >>> (till May 18). If you have any trivial issues or extensions in mind >>> that someone could address within a few days or even hours, that >>> would be perfect. It could even be something like "reformat the >>> printing of these messages" or so. >> >> Replacing some more fprintf(stderr, "foo\n") with error_report("foo") >> comes to mind. :) > > A logical next step after this kind of warmup would be a simple > conversion to error_set(). Perhaps a good place to start would be > qmp_chardev_add(). The switch there has some cases converted already. > Convert one or more of the remaining ones. Beware of the rabbit holes! [snip]
Jumping in on error_set*(), a cute idea might be to evaluate improving error_propagate(). Right now, it just pointer-wise (or contents-wise?) propagates the supplied Error object. This may lead to the root error cause being badly understandable for the end user in a long chain of propagations. Think of realizing a SoC device or a PCI host bridge, which in turn has child objects getting realized, doing things in their realize function that might fail: We may end up getting a standard error such as "Permission denied" without any context of where or why. Compare that to Java where you'd get (too verbose) recursive Exception objects telling you that this failed because that failed because that failed. While it might not be handy to introduce recursively allocated Error objects, simply prepending something to the Error's description should be more easily doable, i.e. error_propagate_foo(errp, local_err, "Foo failed") -> "Foo failed: Original message". On that matter, I had once sprouted the idea of introducing a statically allocated error_oom, similar to error_abort, for avoiding aborts on out-of-memory for user-initiated operations such as hot-add. Unlike the scenario described above, the idea here is to avoid any dynamic allocations, to make it safer to work with guests in low memory situations. This also involves avoiding the aborting object_new() in favor of g_try_malloc() together with a proposed QOM API extension for obtaining the .instance_size of a type: http://patchwork.ozlabs.org/patch/269591/ Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
