On 21/02/2018 04:36, Alexey Kardashevskiy wrote:
> On 19/01/18 16:09, Alexey Kardashevskiy wrote:
>> There is already 'device-list-properties' which does most of the job,
>> however it does not handle everything returned by qom-list-types such
>> as machines as they inherit directly from TYPE_OBJEC
On 19/01/18 16:09, Alexey Kardashevskiy wrote:
> There is already 'device-list-properties' which does most of the job,
> however it does not handle everything returned by qom-list-types such
> as machines as they inherit directly from TYPE_OBJECT and not TYPE_DEVICE.
>
> This adds a new qom-list-p
On Mon, 2018-02-05 at 14:30 +1100, Alexey Kardashevskiy wrote:
> On 02/02/18 18:37, Markus Armbruster wrote:
> > > > Likewise for properties created differently (say with a different type)
> > > > in non-default configuration. We can hope that no such beasts exist.
> > > > Since properties get cre
On 02/02/18 18:37, Markus Armbruster wrote:
> Alexey Kardashevskiy writes:
>
>> On 01/02/18 04:22, Markus Armbruster wrote:
>>> Alexey Kardashevskiy writes:
>>>
There is already 'device-list-properties' which does most of the job,
however it does not handle everything returned by qom-l
Alexey Kardashevskiy writes:
> On 01/02/18 04:22, Markus Armbruster wrote:
>> Alexey Kardashevskiy writes:
>>
>>> There is already 'device-list-properties' which does most of the job,
>>> however it does not handle everything returned by qom-list-types such
>>> as machines as they inherit direc
On 01/02/18 04:22, Markus Armbruster wrote:
> Alexey Kardashevskiy writes:
>
>> There is already 'device-list-properties' which does most of the job,
>> however it does not handle everything returned by qom-list-types such
>> as machines as they inherit directly from TYPE_OBJECT and not TYPE_DEVI
Alexey Kardashevskiy writes:
> There is already 'device-list-properties' which does most of the job,
> however it does not handle everything returned by qom-list-types such
> as machines as they inherit directly from TYPE_OBJECT and not TYPE_DEVICE.
>
> This adds a new qom-list-properties command
Alexey Kardashevskiy writes:
> On 23/01/18 23:49, David Gibson wrote:
>> On Tue, Jan 23, 2018 at 01:03:39PM +0100, Andrea Bolognani wrote:
>>> On Tue, 2018-01-23 at 22:20 +1100, David Gibson wrote:
> David, I know you're busy with linux.conf.au, but it would be
> really helpful if you cou
On 23/01/18 23:49, David Gibson wrote:
> On Tue, Jan 23, 2018 at 01:03:39PM +0100, Andrea Bolognani wrote:
>> On Tue, 2018-01-23 at 22:20 +1100, David Gibson wrote:
David, I know you're busy with linux.conf.au, but it would be
really helpful if you could carve out five minutes to look ove
On Tue, 2018-01-23 at 23:49 +1100, David Gibson wrote:
> It's also occurred to me that making a spapr specific approach to this
> might not be quite as horrible as I initially thought. The
> capabilities table is global (and immutable) so coding up a
> "get-spapr-caps" qapi entry point which encod
On Tue, Jan 23, 2018 at 01:03:39PM +0100, Andrea Bolognani wrote:
> On Tue, 2018-01-23 at 22:20 +1100, David Gibson wrote:
> > > David, I know you're busy with linux.conf.au, but it would be
> > > really helpful if you could carve out five minutes to look over
> > > Alexey's proposal again, with my
On Tue, 2018-01-23 at 22:20 +1100, David Gibson wrote:
> > David, I know you're busy with linux.conf.au, but it would be
> > really helpful if you could carve out five minutes to look over
> > Alexey's proposal again, with my reply above in mind, and let us
> > know whether it looks a reasonable de
On Tue, Jan 23, 2018 at 11:08:31AM +0100, Andrea Bolognani wrote:
> On Fri, 2018-01-19 at 15:34 +0100, Andrea Bolognani wrote:
> > > > This won't solve the libvirt problem we were discussing, because it
> > > > needs an existing instance of the object. libvirt wants to know the
> > > > machine pro
On Fri, 2018-01-19 at 15:34 +0100, Andrea Bolognani wrote:
> > > This won't solve the libvirt problem we were discussing, because it
> > > needs an existing instance of the object. libvirt wants to know the
> > > machine properties *without* instantiating an instance.
> >
> > My patch works with
On Fri, 2018-01-19 at 17:15 +1100, Alexey Kardashevskiy wrote:
> > I think the existing qom-list interface does this already.
>
> Nope, it does not. It takes path, not a type, so running with "-machine
> none" won't help.
>
> > This won't solve the libvirt problem we were discussing, because it
>
On 19/01/18 17:15, Alexey Kardashevskiy wrote:
> On 19/01/18 16:19, David Gibson wrote:
>> On Fri, Jan 19, 2018 at 04:09:06PM +1100, Alexey Kardashevskiy wrote:
>>> There is already 'device-list-properties' which does most of the job,
>>> however it does not handle everything returned by qom-list-t
On 19/01/18 16:19, David Gibson wrote:
> On Fri, Jan 19, 2018 at 04:09:06PM +1100, Alexey Kardashevskiy wrote:
>> There is already 'device-list-properties' which does most of the job,
>> however it does not handle everything returned by qom-list-types such
>> as machines as they inherit directly fr
On Fri, Jan 19, 2018 at 04:09:06PM +1100, Alexey Kardashevskiy wrote:
> There is already 'device-list-properties' which does most of the job,
> however it does not handle everything returned by qom-list-types such
> as machines as they inherit directly from TYPE_OBJECT and not TYPE_DEVICE.
>
> Thi
There is already 'device-list-properties' which does most of the job,
however it does not handle everything returned by qom-list-types such
as machines as they inherit directly from TYPE_OBJECT and not TYPE_DEVICE.
This adds a new qom-list-properties command which prints properties
of a specific c
19 matches
Mail list logo
