[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 3/4] vl: add -object option to create QOM object

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 3/4] vl: add -object option to create QOM objects from the command line
Date: Tue, 26 Jun 2012 18:57:42 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 06/26/2012 03:42 AM, Markus Armbruster wrote:
>> Anthony Liguori<address@hidden>  writes:
>>> This will create a new QOM object in the '/objects' path.  Note that 
>>> properties
>> Long line, will look fugly in git-log.  Please wrap at column 70-75.
> Okay, let me turn this around:
> How do people normally limit this beyond just eye-balling?  My

Use a real editor?  That's what I do.  Emacs has the fill-column set to
70 in by default.  I'm not familiar with the eVIl one, but I'd expect it
to have something similar.

> terminals are 80-width as god intended them to be.  Trying to guess
> whether you cross 75 or not seems to be a bit silly.  git also doesn't
> do anything helpful like stick an indicator in the comments below the
> message where the 75 character mark is.
>> checkpatch.pl complains about long lines in the patch proper, too :)
> checkpatch.pl is dumb.  I don't see any long lines in the patch...

Let me run it for you:

WARNING: line over 80 characters
#181: FILE: vl.c:2259:
+static int object_set_property(const char *name, const char *value, void 

WARNING: line over 80 characters
#245: FILE: vl.c:3260:
+    if (qemu_opts_foreach(qemu_find_opts("object"), object_create, NULL, 0) != 
0) {

total: 0 errors, 2 warnings, 115 lines checked

Correct on both counts.

>>> are set in order which allows for simple objects to be initialized entirely
>>> with this option and then realized.
>> Is there any way to avoid making the option order significant?  I find
>> that a rather poor user interface.
> Hrm, I tried very hard to make sure it was significant.  Otherwise you
> can't do something like:
> -object rng-urandom,filename=/dev/foo,opened=true
> b/c filename needs to be set before opened gets set since filename is
> checked to be != NULL when opened is set to true.

That's because "opened" is really a method disguising as property.
Maybe that's not such a hot idea.

>>> This option is roughly equivalent to -device but for things that are not
>>> devices.
>>> diff --git a/qemu-options.hx b/qemu-options.hx
>>> index 8b66264..20cfe1c 100644
>>> --- a/qemu-options.hx
>>> +++ b/qemu-options.hx
>>> @@ -2743,6 +2743,14 @@ DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log,
>>>       "-qtest-log LOG  specify tracing options\n",
>>>       QEMU_ARCH_ALL)
>>> +DEF("object", HAS_ARG, QEMU_OPTION_object,
>>> +    "-object TYPENAME[,PROP1=VALUE1,...]\n"
>>> +    "                create an new object of type TYPENAME setting 
>>> properties\n"
>>> +    "                in the order they are specified.  Note that the 
>>> 'id'\n"
>>> +    "                property must be set.  These objects are placed in 
>>> the\n"
>>> +    "                '/objects' path.\n",
>>> +    QEMU_ARCH_ALL)
>>> +
>> Could you explain why putting these into /objects always is fine?
>> Doesn't this mean that -object is *not* more general than -device?
> Every path is a unique namespace.  I'm sticking everything in /objects
> right now because it's a unique namespace that won't conflict with
> other namespaces (like /block or /peripheral).  I wish we only used
> one unique namespace because then we can just refer to short names
> which is why I didn't introduce a /rng namespace.

I have to admit that the intended roles of the various containers /
namespaces are unclear to me.

> Using a single namespace makes it easier to work with paths because
> then you can rely on partial path resolution.


> At some point, we will truly want -device to be an alias for -object
> and then we'll probably want to add a qom-container argument to
> -object in order to specify which container the object should be
> created in.
> But I didn't do it here because I don't want people placing things in
> random containers.

Yet.  Since you "probably want to add a qom-container argument"


reply via email to

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