Re: [Qemu-devel] [GSoC] Wanted: small warmup tasks

[Andreas Färber]

Am 25.04.2014 08:38, schrieb Markus Armbruster:
> Andreas Färber <address@hidden> 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