On Fri, 6 Jun 2014 19:21:36 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Fri, Jun 06, 2014 at 11:38:58PM +0200, Igor Mammedov wrote: > > On Fri, 6 Jun 2014 17:14:29 -0300 > > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > > This avoids QEMU from aborting on cases like this: > > > > > > $ ./install/bin/qemu-system-x86_64 -global cpu.foobar=5 > > > qemu-system-x86_64: Property '.foobar' not found > > > Aborted (core dumped) > > That is expected behavior. > > Why? > > QEMU should never dump core due to user error. > > QEMU should not abort when handling a device_add command due to user > error. I've meant QEMU shouldn't start if CLI has error. whether it's abort or exit(FAIL) doesn't matter much. > > > > > > > > > The code sets dev->not_used if the property is not found as an effort to > > > to allow errors to be reported even if the device is hotpluggable, but > > > it won't catch all errors. We can't know the property is not going to be > > > available for hotpluggable devices, unless we actually try to create the > > > device. > > Instead of ignoring users errors, DeviceState should have async_error > > field which could be set by device_post_init() instead of aborting and > > later device_add could gracefully fail hotadd operation if error is set. > > > > PS: > > initfn-s could also reuse this, instead of ignoring errors as they do now. > > Your proposal sounds good, and would allow reporting error without > creating an object_new() variation that accepts Error**. > > But I believe we need to choose what to do in the meantime, while we > don't have that mechanism implemented. Dumping core is not acceptable. > Exiting QEMU while handling device_add doesn't seem acceptable to me, > either. Exiting at startup is fine and allows to filter out user errors early. During hotplug exiting is certainly not an option, that's why I'm suggesting add async_error so that hotplug operation could fail gracefully. It's a cleaner approach and not much more complex. Ignoring errors on the other side would introduce relaxed CLI interface that we would have to support forever for compatibility reasons. > > -- > Eduardo -- Regards, Igor