qemu-devel
[Top][All Lists]
Advanced

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

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


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH] qdev: Skip non-existing properties when setting globals
Date: Fri, 6 Jun 2014 22:09:18 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Jun 07, 2014 at 12:45:26AM +0100, Peter Maydell wrote:
> On 7 June 2014 00:22, Igor Mammedov <address@hidden> wrote:
> > Eduardo Habkost <address@hidden> wrote:
> >> On Fri, Jun 06, 2014 at 11:38:58PM +0200, Igor Mammedov wrote:
> >> > Eduardo Habkost <address@hidden> wrote:
> >> > >   $ ./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.
> 
> I'm with Eduardo on this one -- if the user passes us a bad
> command line we should diagnose it helpfully and exit with
> a failure code; abort() is for programming errors. (If nothing
> else, using abort() for user-triggerable conditions tends to
> mean we get bug reports about core dumps, so it's in our
> own interest to not do that :-) )

So you are agreeing with Igor, as well. He is just suggesting we keep
terminating QEMU on that case, and we can use exit() for that. My patch,
on the other hand, makes QEMU not terminate on those cases.

Note that we have two different bugs:

1) QEMU core dumps in case of user error. This is a regression
   introduced in 1.7.0. It can be fixed easily by changing existing code
   to use exit() instead of aborting.
2) QEMU terminating on device_add in case of user error. This bug was
   always present. It can be addressed using the async_error approach
   suggested by Igor.

I will submit a new patch to address (1), first.

-- 
Eduardo



reply via email to

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