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

[Markus Armbruster <armbru@redhat.com>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 18 July 2012 12:19, Markus Armbruster <armbru@redhat.com> wrote:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>
>>> n 18 July 2012 11:20, Andreas Färber <afaerber@suse.de> 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 <peter.maydell@linaro.org>
>>>>> ---
>>>>> 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...

I'm not objecting to your patch (I didn't even review it), just pointing
out there's a glimmer of hope on the "emitting error messages fit for
humans is somewhere between difficult and impossible" front.