qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] qerror: Add QERR_PROPERTY_SET_AFTER_REALIZE


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2] qerror: Add QERR_PROPERTY_SET_AFTER_REALIZE
Date: Wed, 18 Jul 2012 12:36:26 +0100

On 18 July 2012 12:19, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>
>> n 18 July 2012 11:20, Andreas Färber <address@hidden> wrote:
>>> Am 16.07.2012 17:25, schrieb Peter Maydell:
>>>> Add a new QError QERR_PROPERTY_SET_AFTER_REALIZE for attempts
>>>> to set a QOM or qdev property after the object/device has been
>>>> realized. This allows a slightly more informative diagnostic
>>>> than the previous "permission denied" message.
>>>>
>>>> Signed-off-by: Peter Maydell <address@hidden>
>>>> ---
>>>> Changes since the v1 (which was sent way back in March...):
>>>>  * rebased on master now a pile of qdev/qom changesd have landed
>>>>  * fixed some overlong lines
>>>>  * avoid gcc '?:' extension
>>>>  * a couple of set_ functions in qdev-properties.c are new since v1
>>>>    and needed their QERR_PERMISSION_DENIED checks changing
>>>
>>> This does not yet seem to take into account the discussion with libvirt
>>> and Anthony on what parameters to pass. The ID generalization was
>>> nack'ed by Anthony and a QOM path was suggested as alternative. Could
>>> you please look into that?
>>
>> I'm afraid I'm not really sure what you're referring to here --
>> do you have a link to a discussion?
>>
>> All I want is for errors printed to the user to be a bit more
>> helpful; the whole qerror infrastructure seems to make it
>> somewhere between difficult and impossible to do that :-(
>
> Yup.  One of the reasons why I detest it.
>
> A recent thread on how to recover from this disaster:
> http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg03469.html

That's interesting but I'm not sure how it's relevant. We already
have QERR_PROPERTY values just this new one, so I don't see why
this is any worse than the ones we have. If we come up with some
new scheme we can convert this with all the rest. And I don't
really want to block "improve this error message" on getting
agreement for some big redesign effort...

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]