On 01/31/13 17:13, Peter Maydell wrote: > On 31 January 2013 16:05, Laszlo Ersek <ler...@redhat.com> 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