[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new |
Date: |
Thu, 24 May 2012 16:31:01 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 |
Am 24.05.2012 16:08, schrieb Markus Armbruster:
> Andreas Färber <address@hidden> writes:
>
>> Am 24.05.2012 13:43, schrieb Markus Armbruster:
>>> Beware: second patch is the product of voodoo-coding.
>>
>> Hm, I don't like the voodoo. ;) I would rather expose a proper C API
>> like object_try_new(const char *, Error **) than opening up the TypeImpl
>> internals to the public and hand-coding it everywhere.
>
> How does returning a TypeImpl * open up TypeImpl any more than
> type_register() already does?
type_register[_static]() operates on TypeInfo, not TypeImpl.
I consider TypeImpl an implementation detail of qom/object.c, but maybe
I'm mistaken.
>> similar error-catching scenario where I needed to check for class
>> existence in some qdev_try_* function.
>
> If this is a really common pattern, and object_try_new() really saves
> code, why not.
>
> Can't see why we need the Error **argument, though. What kinds of
> different errors that do you envisage? Where "different" means "actual
> callers care about the difference".
Well, I thought of class-doesn't-exist vs. out-of-memory. It would just
be to report different textual messages to the end user - as QMP error
response or as stderr output elsewhere. I have better OOM handling
somewhere down my TODO list, including a preallocated Error object. Main
reason is avoiding code duplication though.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
- Re: [Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new, (continued)
- [Qemu-devel] [PATCH RFC 1/2] qom: Give type_get_by_name() external linkage, Markus Armbruster, 2012/05/24
- Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new, Andreas Färber, 2012/05/24
- Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new, Anthony Liguori, 2012/05/24
- Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new, Peter Maydell, 2012/05/24
- Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new, Anthony Liguori, 2012/05/24
- Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new, Peter Maydell, 2012/05/24
- Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new, Anthony Liguori, 2012/05/24
- Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new, Peter Maydell, 2012/05/24
Re: [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new, Markus Armbruster, 2012/05/24