Paolo Bonzini writes:
> Il 22/09/2014 13:43, Markus Armbruster ha scritto:
>> Paolo Bonzini writes:
>>
>>> Il 22/09/2014 10:34, Michael S. Tsirkin ha scritto:
Basically this patch brings back historical HMP behaviour.
As far as I could tell, it wasn't changed intentionally.
>>>
>>> It
Paolo Bonzini writes:
> Il 23/09/2014 05:09, Gonglei (Arei) ha scritto:
>> Hi,
>>
>>> This doesn't change the fact that ObjectProperty is a generic struct,
>>> and adding alias-specific fields there is wrong.
>>
>> OK, Maybe I should find other ways to attach this purpose and
>>>
> Subject: Re: [PATCH 0/3] Fix confused output for alias properties
>
> Il 23/09/2014 05:09, Gonglei (Arei) ha scritto:
> > Hi,
> >
> >> This doesn't change the fact that ObjectProperty is a generic struct,
> >> and adding alias-specific fields there is wrong.
> >
> > OK, Maybe I s
u-devel@nongnu.org;
> aligu...@amazon.com; lcapitul...@redhat.com
> Subject: Re: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties
>
> "Gonglei (Arei)" writes:
>
> > Hi,
> >
> >> >>>> This doesn't change the fact that Object
On Tue, Sep 23, 2014 at 11:06:02AM +0200, Markus Armbruster wrote:
> "Gonglei (Arei)" writes:
>
> > Hi,
> >
> >> This doesn't change the fact that ObjectProperty is a generic struct,
> >> and adding alias-specific fields there is wrong.
> >> >>>
> >> >>> OK, Maybe I should find other wa
"Gonglei (Arei)" writes:
> Hi,
>
>> This doesn't change the fact that ObjectProperty is a generic struct,
>> and adding alias-specific fields there is wrong.
>> >>>
>> >>> OK, Maybe I should find other ways to attach this purpose and
>> >>> avoid layering violation. Thanks!
>> >>
>> >>
Il 23/09/2014 05:09, Gonglei (Arei) ha scritto:
> Hi,
>
>> This doesn't change the fact that ObjectProperty is a generic struct,
>> and adding alias-specific fields there is wrong.
>
> OK, Maybe I should find other ways to attach this purpose and
> avoid layering violation. Tha
On Mon, Sep 22, 2014 at 03:08:09PM +0200, Paolo Bonzini wrote:
> Of course, with every new feature we would most likely have yet another
> unfinished transition. In the lack of a clear user complaint (or even
> of a clear indication that human users ever used -device foo,help...)
> the tempation t
Hi,
> This doesn't change the fact that ObjectProperty is a generic struct,
> and adding alias-specific fields there is wrong.
> >>>
> >>> OK, Maybe I should find other ways to attach this purpose and
> >>> avoid layering violation. Thanks!
> >>
> >> Unfortunately I cannot think of any.
> Subject: Re: [PATCH 0/3] Fix confused output for alias properties
>
> Il 22/09/2014 15:36, Gonglei (Arei) ha scritto:
> >> If the field is called "opaque", it's opaque.
> >
> > Sorry?
>
> The field is called "opaque" because no one, except the callbacks,
> should look into that field. Casting
Il 22/09/2014 15:36, Gonglei (Arei) ha scritto:
>> If the field is called "opaque", it's opaque.
>
> Sorry?
The field is called "opaque" because no one, except the callbacks,
should look into that field. Casting it to AliasProperty breaks that rule.
Paolo
> Subject: Re: [PATCH 0/3] Fix confused output for alias properties
>
> Il 22/09/2014 15:13, Gonglei (Arei) ha scritto:
> > (I don't add alias-sepecific filed into ObjectProperty
> > struct, just add a bool property. )
> >
> > diff --git a/include/qom/object.h b/include/qom/object.h
> > index 8a05
Il 22/09/2014 15:13, Gonglei (Arei) ha scritto:
> (I don't add alias-sepecific filed into ObjectProperty
> struct, just add a bool property. )
>
> diff --git a/include/qom/object.h b/include/qom/object.h
> index 8a05a81..8b8ded5 100644
> --- a/include/qom/object.h
> +++ b/include/qom/object.h
> @@
> > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> > Bonzini
> > Sent: Monday, September 22, 2014 8:07 PM
> > To: Gonglei (Arei); Michael S. Tsirkin
> > Cc: ag...@suse.de; Huangweidong (C); aligu...@amazon.com; Huangpeng
> > (Peter); qemu-devel@nongnu.org; stefa...@redhat
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, September 22, 2014 8:07 PM
> To: Gonglei (Arei); Michael S. Tsirkin
> Cc: ag...@suse.de; Huangweidong (C); aligu...@amazon.com; Huangpeng
> (Peter); qemu-devel@nong
Il 22/09/2014 13:43, Markus Armbruster ha scritto:
> Paolo Bonzini writes:
>
>> Il 22/09/2014 10:34, Michael S. Tsirkin ha scritto:
>>> Basically this patch brings back historical HMP behaviour.
>>> As far as I could tell, it wasn't changed intentionally.
>>
>> It was changed intentionally. Or r
Il 22/09/2014 14:34, Michael S. Tsirkin ha scritto:
> On Mon, Sep 22, 2014 at 02:06:38PM +0200, Paolo Bonzini wrote:
>> Il 22/09/2014 13:22, Gonglei (Arei) ha scritto:
This doesn't change the fact that ObjectProperty is a generic struct,
and adding alias-specific fields there is wrong.
>>
Paolo Bonzini writes:
> Il 22/09/2014 13:22, Gonglei (Arei) ha scritto:
>> > This doesn't change the fact that ObjectProperty is a generic struct,
>> > and adding alias-specific fields there is wrong.
>>
>> OK, Maybe I should find other ways to attach this purpose and
>> avoid layering violation
On Mon, Sep 22, 2014 at 02:06:38PM +0200, Paolo Bonzini wrote:
> Il 22/09/2014 13:22, Gonglei (Arei) ha scritto:
> > > This doesn't change the fact that ObjectProperty is a generic struct,
> > > and adding alias-specific fields there is wrong.
> >
> > OK, Maybe I should find other ways to attach t
Il 22/09/2014 13:22, Gonglei (Arei) ha scritto:
> > This doesn't change the fact that ObjectProperty is a generic struct,
> > and adding alias-specific fields there is wrong.
>
> OK, Maybe I should find other ways to attach this purpose and
> avoid layering violation. Thanks!
Unfortunately I cann
Paolo Bonzini writes:
> Il 22/09/2014 10:34, Michael S. Tsirkin ha scritto:
>> Basically this patch brings back historical HMP behaviour.
>> As far as I could tell, it wasn't changed intentionally.
>
> It was changed intentionally. Or rather, the change was known at the
> time Stefan made it.
C
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, September 22, 2014 6:04 PM
> To: Gonglei (Arei); Michael S. Tsirkin
> Cc: Huangweidong (C); aligu...@amazon.com; qemu-devel@nongnu.org;
> ag...@suse.de; stefa...@redhat.com; Huangpeng (Peter);
> lcap
Il 22/09/2014 11:33, Gonglei (Arei) ha scritto:
> Yes, I knew this issue which object A's property name may
> is not the same with object B, so I had posted v2 to fix it.
This doesn't change the fact that ObjectProperty is a generic struct,
and adding alias-specific fields there is wrong.
Paolo
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, September 22, 2014 5:15 PM
> To: Michael S. Tsirkin; Gonglei (Arei)
> Cc: ag...@suse.de; Huangweidong (C); aligu...@amazon.com; Huangpeng
> (Peter); qemu-devel@nongnu.org; stefa...@redhat.com;
> lcap
"Michael S. Tsirkin" writes:
> On Mon, Sep 15, 2014 at 10:44:36PM +0800, arei.gong...@huawei.com wrote:
>> From: Gonglei
>>
>> At present, people have no way to know they should
>> have a specific format for alias properties.
>>
>> Example:
>>
>> before output:
>>
>> virtio-blk-pci.physical
Il 22/09/2014 10:34, Michael S. Tsirkin ha scritto:
> Basically this patch brings back historical HMP behaviour.
> As far as I could tell, it wasn't changed intentionally.
It was changed intentionally. Or rather, the change was known at the
time Stefan made it.
> So how about applying this first
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Monday, September 22, 2014 4:34 PM
> Subject: Re: [PATCH 0/3] Fix confused output for alias properties
>
> On Mon, Sep 15, 2014 at 10:44:36PM +0800, arei.gong...@huawei.com wrote:
> > From: Gonglei
> >
> > At present, people have no way
On Mon, Sep 15, 2014 at 10:44:36PM +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> At present, people have no way to know they should
> have a specific format for alias properties.
>
> Example:
>
> before output:
>
> virtio-blk-pci.physical_block_size=uint16
> virtio-blk-pci.logical
dhat.com; Huangpeng
> (Peter); lcapitul...@redhat.com
> Subject: RE: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties
>
> > From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> > Sent: Tuesday, September 16, 2014 10:37 PM
> > Subject: Re: [Qemu-devel] [P
On 09/16/2014 11:54 PM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> On 09/16/2014 12:31 PM, Paolo Bonzini wrote:
>>
Change legacy_name to point to a detailed human-readable
description of the type?
E.g. "Ethernet 6-byte MAC Address, format: AA:BB:CC:DD:EE:FF"?
>>>
>>> If lib
"Michael S. Tsirkin" writes:
> On Tue, Sep 16, 2014 at 10:01:19PM +0300, Michael S. Tsirkin wrote:
>> On Tue, Sep 16, 2014 at 08:31:08PM +0200, Paolo Bonzini wrote:
>> > Il 16/09/2014 18:56, Michael S. Tsirkin ha scritto:
>> > > On Tue, Sep 16, 2014 at 06:27:51PM +0200, Paolo Bonzini wrote:
>> >
Eric Blake writes:
> On 09/16/2014 12:31 PM, Paolo Bonzini wrote:
>
>>> Change legacy_name to point to a detailed human-readable
>>> description of the type?
>>> E.g. "Ethernet 6-byte MAC Address, format: AA:BB:CC:DD:EE:FF"?
>>
>> If libvirt can cope with
>>
>> e1000.mac=str (Ethernet 6-byte MA
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, September 16, 2014 10:37 PM
> Subject: Re: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties
>
> Il 16/09/2014 16:32, Markus Armbruster ha scritto:
> > Paolo Bonzini writes:
> >
>
On 09/16/2014 12:31 PM, Paolo Bonzini wrote:
>> Change legacy_name to point to a detailed human-readable
>> description of the type?
>> E.g. "Ethernet 6-byte MAC Address, format: AA:BB:CC:DD:EE:FF"?
>
> If libvirt can cope with
>
> e1000.mac=str (Ethernet 6-byte MAC Address, format: AA:BB:CC:DD:
On Tue, Sep 16, 2014 at 10:01:19PM +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 16, 2014 at 08:31:08PM +0200, Paolo Bonzini wrote:
> > Il 16/09/2014 18:56, Michael S. Tsirkin ha scritto:
> > > On Tue, Sep 16, 2014 at 06:27:51PM +0200, Paolo Bonzini wrote:
> > >> Il 16/09/2014 18:26, Michael S. Ts
On Tue, Sep 16, 2014 at 08:31:08PM +0200, Paolo Bonzini wrote:
> Il 16/09/2014 18:56, Michael S. Tsirkin ha scritto:
> > On Tue, Sep 16, 2014 at 06:27:51PM +0200, Paolo Bonzini wrote:
> >> Il 16/09/2014 18:26, Michael S. Tsirkin ha scritto:
> >>> Right so types should be explicit.
> >>> If an arbit
Il 16/09/2014 18:56, Michael S. Tsirkin ha scritto:
> On Tue, Sep 16, 2014 at 06:27:51PM +0200, Paolo Bonzini wrote:
>> Il 16/09/2014 18:26, Michael S. Tsirkin ha scritto:
>>> Right so types should be explicit.
>>> If an arbitrary string isn't allowed, this should be documented.
>>> It's not great
On Tue, Sep 16, 2014 at 06:27:51PM +0200, Paolo Bonzini wrote:
> Il 16/09/2014 18:26, Michael S. Tsirkin ha scritto:
> > Right so types should be explicit.
> > If an arbitrary string isn't allowed, this should be documented.
> > It's not great as is: what's the format for macaddr? AA:BB:CC:DD:EE:FF
On Tue, Sep 16, 2014 at 12:45:43PM +0200, Paolo Bonzini wrote:
> Il 16/09/2014 12:37, Michael S. Tsirkin ha scritto:
> > str really should be for free-form strings.
> > It makes as much sense to call it as string
>
> Yes, that's why I said drive->str is a degradation. The question is,
> how impor
Il 16/09/2014 18:26, Michael S. Tsirkin ha scritto:
> Right so types should be explicit.
> If an arbitrary string isn't allowed, this should be documented.
> It's not great as is: what's the format for macaddr? AA:BB:CC:DD:EE:FF?
> aa:bb:cc:dd:ee:ff? aabbccddeeff? 0xaabbccddeeff?
> But just saying
Paolo Bonzini writes:
> Il 16/09/2014 11:16, Markus Armbruster ha scritto:
>>> I think both "str" and "link" actually are a small
>>> degradation
>>> compared to "drive", and this is why I kept the legacy_name. But overall I
>>> think it's not really worth the layering violation that patches 2
Il 16/09/2014 16:32, Markus Armbruster ha scritto:
> Paolo Bonzini writes:
>
>> Il 16/09/2014 11:16, Markus Armbruster ha scritto:
I think both "str" and "link" actually are a small
degradation
compared to "drive", and this is why I kept the legacy_name. But overall I
think
Hi,
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, September 16, 2014 6:46 PM
> Subject: Re: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties
>
> Il 16/09/2014 12:37, Michael S. Tsirkin ha scritto:
> > str really should be for free-form
On Tue, Sep 16, 2014 at 11:34:07AM +0200, Paolo Bonzini wrote:
> Il 16/09/2014 11:16, Markus Armbruster ha scritto:
> >> I think both "str" and "link" actually are a small
> >> degradation
> >> compared to "drive", and this is why I kept the legacy_name. But overall I
> >> think it's not really w
Il 16/09/2014 12:37, Michael S. Tsirkin ha scritto:
> str really should be for free-form strings.
> It makes as much sense to call it as string
Yes, that's why I said drive->str is a degradation. The question is,
how important is that degradation?
> as it is to call an integer a string because y
Il 16/09/2014 11:16, Markus Armbruster ha scritto:
>> I think both "str" and "link" actually are a small degradation
>> compared to "drive", and this is why I kept the legacy_name. But overall I
>> think it's not really worth the layering violation that patches 2 and 3 are;
>> and it's definitely
Paolo Bonzini writes:
> Il 16/09/2014 09:21, Markus Armbruster ha scritto:
>> The rebase onto QOM renamed name to legacy_name, to free name for use as
>> QOM type name (commit cafe5bd).
>
> Also, the QOM type name has strict rules:
>
> - either it is a QAPI type (primitive, enum or struct)
>
> -
Il 15/09/2014 19:49, Michael S. Tsirkin ha scritto:
> On Mon, Sep 15, 2014 at 10:44:36PM +0800, arei.gong...@huawei.com wrote:
>> From: Gonglei
>>
>> At present, people have no way to know they should
>> have a specific format for alias properties.
>>
>> Example:
>>
>> before output:
>>
>> virtio
Il 16/09/2014 09:21, Markus Armbruster ha scritto:
> The rebase onto QOM renamed name to legacy_name, to free name for use as
> QOM type name (commit cafe5bd).
Also, the QOM type name has strict rules:
- either it is a QAPI type (primitive, enum or struct)
- or it is link
- or it is child
The
> From: Markus Armbruster [mailto:arm...@redhat.com]
> Sent: Tuesday, September 16, 2014 3:21 PM
> To: Michael S. Tsirkin
> Subject: Re: [Qemu-devel] [PATCH 0/3] Fix confused output for alias properties
>
> "Michael S. Tsirkin" writes:
>
> > On Mon, Se
"Michael S. Tsirkin" writes:
> On Mon, Sep 15, 2014 at 05:57:51PM +0200, Paolo Bonzini wrote:
>> Il 15/09/2014 16:44, arei.gong...@huawei.com ha scritto:
>> > From: Gonglei
>> >
>> > At present, people have no way to know they should
>> > have a specific format for alias properties.
>> >
>> >
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Subject: Re: [PATCH 0/3] Fix confused output for alias properties
>
> On Mon, Sep 15, 2014 at 10:44:36PM +0800, arei.gong...@huawei.com wrote:
> > From: Gonglei
> >
> > At present, people have no way to know they should
> > have a specific for
On Mon, Sep 15, 2014 at 10:44:36PM +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> At present, people have no way to know they should
> have a specific format for alias properties.
>
> Example:
>
> before output:
>
> virtio-blk-pci.physical_block_size=uint16
> virtio-blk-pci.logical
On Mon, Sep 15, 2014 at 10:44:36PM +0800, arei.gong...@huawei.com wrote:
> From: Gonglei
>
> At present, people have no way to know they should
> have a specific format for alias properties.
>
> Example:
>
> before output:
>
> virtio-blk-pci.physical_block_size=uint16
> virtio-blk-pci.logical
On Mon, Sep 15, 2014 at 05:57:51PM +0200, Paolo Bonzini wrote:
> Il 15/09/2014 16:44, arei.gong...@huawei.com ha scritto:
> > From: Gonglei
> >
> > At present, people have no way to know they should
> > have a specific format for alias properties.
> >
> > Example:
> >
> > before output:
> >
>
On 09/15/2014 09:57 AM, Paolo Bonzini wrote:
> Il 15/09/2014 16:44, arei.gong...@huawei.com ha scritto:
>> From: Gonglei
>>
>> At present, people have no way to know they should
>> have a specific format for alias properties.
>>
>> Example:
>>
>> before output:
>>
>> virtio-blk-pci.physical_block
Il 15/09/2014 16:44, arei.gong...@huawei.com ha scritto:
> From: Gonglei
>
> At present, people have no way to know they should
> have a specific format for alias properties.
>
> Example:
>
> before output:
>
> virtio-blk-pci.physical_block_size=uint16
> virtio-blk-pci.logical_block_size=uint
From: Gonglei
At present, people have no way to know they should
have a specific format for alias properties.
Example:
before output:
virtio-blk-pci.physical_block_size=uint16
virtio-blk-pci.logical_block_size=uint16
virtio-blk-pci.drive=str
after output applied this patch series:
virtio-bl
58 matches
Mail list logo
