Re: [Qemu-devel] [PATCH] qdev: Skip non-existing properties when setting globals

[Igor Mammedov]

On Fri, 6 Jun 2014 19:21:36 -0300
Eduardo Habkost <address@hidden> 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 <address@hidden> 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