Anthony Liguori <aligu...@us.ibm.com> writes:
> On 06/26/2012 03:42 AM, Markus Armbruster wrote:
>> Anthony Liguori<aligu...@us.ibm.com> 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
*opaque)
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.
-v?
> 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"
anyway...
[...]
