qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 2/2] qbus_find_recursive(): the "free slots" const


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [RFC 2/2] qbus_find_recursive(): the "free slots" constraint needs a dedicated error
Date: Thu, 31 Jan 2013 17:36:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130108 Thunderbird/10.0.12

On 01/31/13 17:13, Peter Maydell wrote:
> On 31 January 2013 16:05, Laszlo Ersek <address@hidden> wrote:
>> On 01/31/13 16:54, Peter Maydell wrote:
>>> I thought we weren't adding any new QERR errors any more?
>>
>> How do you intend to inform the user about new error situations? If
>> error codes are a fixed set, then we need either a facility for freely
>> extending text in the error object, or for stacking separate messages in
>> the error object.
> 
> The idea IIRC is that we just report everything with a free
> text message and a generic error class (apart from the legacy
> existing error classes).

That is the polar opposite of what I'm trying to do; namely,
accumulating all info & error messages up to do_device_add(), and
branching hmp from qmp only above it. The internals should become fully
silent.

Of course the calltree rooted in do_device_add() prints a lot of
informative text (not errors) as well "if !qmp": qbus_list_bus(),
qbus_list_dev(), qdev_device_help() etc.

I don't yet have details in mind for those, but people have convinced me
that the grand idea would be extracting those info printouts as well (as
separate top-level operations), extracting / reusing the path resolution
code from the actual do_device_add() code.

As first step I'm attacking the errors. I'm glad we found this conflict
wrt. error propagation this early, as any further steps depend on it.

Thanks!
Laszlo



reply via email to

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