On Thu, Dec 03, 2020 at 07:10:37PM +0100, Paolo Bonzini wrote:
> On 03/12/20 18:52, Eduardo Habkost wrote:
> > On Thu, Dec 03, 2020 at 05:50:46PM +0100, Paolo Bonzini wrote:
> > > On 03/12/20 16:15, Kevin Wolf wrote:
> > > > I don't think this is an intermediate state like Eduardo wants to have.
>
On 03/12/20 18:52, Eduardo Habkost wrote:
On Thu, Dec 03, 2020 at 05:50:46PM +0100, Paolo Bonzini wrote:
On 03/12/20 16:15, Kevin Wolf wrote:
I don't think this is an intermediate state like Eduardo wants to have.
Creating the object, then setting properties, then realize [1] will fail
after
On 03/12/20 18:43, Kevin Wolf wrote:
I think I'd want to do step 2 and 3 combined, because converting
user-creatable objects to oc->configure means manually writing the
configure function that will be generated from QAPI in step 3. Writing
code just to throw it away isn't my favourite pastime.
On Thu, Dec 03, 2020 at 05:50:46PM +0100, Paolo Bonzini wrote:
> On 03/12/20 16:15, Kevin Wolf wrote:
> > I don't think this is an intermediate state like Eduardo wants to have.
> > Creating the object, then setting properties, then realize [1] will fail
> > after your change. But keeping it
Am 03.12.2020 um 17:50 hat Paolo Bonzini geschrieben:
> On 03/12/20 16:15, Kevin Wolf wrote:
> > I don't think this is an intermediate state like Eduardo wants to have.
> > Creating the object, then setting properties, then realize [1] will fail
> > after your change. But keeping it working was
On 03/12/20 16:15, Kevin Wolf wrote:
I don't think this is an intermediate state like Eduardo wants to have.
Creating the object, then setting properties, then realize [1] will fail
after your change. But keeping it working was the whole point of the
exercise.
With the sample code, you must
Am 03.12.2020 um 12:11 hat Paolo Bonzini geschrieben:
> On 02/12/20 18:35, Kevin Wolf wrote:
> > > Could we have an intermediate state that doesn't require any
> > > duplication and thus have no separate code paths that could
> > > diverge?
> >
> > The one requirement we have for an intermediate
On Thu, Dec 03, 2020 at 07:46:29AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > It would be much nicer to do the wrapper the other way round, i.e.
> > setting properties before the device is realized would update a
> > configuration struct and realize would then call .create() with that
> > struct.
On 02/12/20 18:35, Kevin Wolf wrote:
Could we have an intermediate state that doesn't require any
duplication and thus have no separate code paths that could
diverge?
The one requirement we have for an intermediate state is that it
supports both interfaces: The well-know create/set
Hi,
> It would be much nicer to do the wrapper the other way round, i.e.
> setting properties before the device is realized would update a
> configuration struct and realize would then call .create() with that
> struct. To me, this sounds much harder, though also a more useful state.
Well, in
On Wed, Dec 02, 2020 at 06:35:06PM +0100, Kevin Wolf wrote:
> Am 02.12.2020 um 17:05 hat Eduardo Habkost geschrieben:
> > > > Looks nice as end goal. Then, these are a few questions I would
> > > > have about the transition plan:
> > > >
> > > > Would it require changing both device
Am 02.12.2020 um 17:05 hat Eduardo Habkost geschrieben:
> > > Looks nice as end goal. Then, these are a few questions I would
> > > have about the transition plan:
> > >
> > > Would it require changing both device implementation and device
> > > users in lockstep? Should we have a compatibility
On Wed, Dec 02, 2020 at 04:17:13PM +0100, Kevin Wolf wrote:
> Am 02.12.2020 um 14:54 hat Eduardo Habkost geschrieben:
> > On Wed, Dec 02, 2020 at 02:26:44PM +0100, Paolo Bonzini wrote:
> > > On 02/12/20 13:51, Eduardo Habkost wrote:
> > > > > > I'm liking the direction this is taking. However, I
Am 02.12.2020 um 14:54 hat Eduardo Habkost geschrieben:
> On Wed, Dec 02, 2020 at 02:26:44PM +0100, Paolo Bonzini wrote:
> > On 02/12/20 13:51, Eduardo Habkost wrote:
> > > > > I'm liking the direction this is taking. However, I would still
> > > > > like to have a clearer and feasible plan that
On Wed, Dec 02, 2020 at 02:26:44PM +0100, Paolo Bonzini wrote:
> On 02/12/20 13:51, Eduardo Habkost wrote:
> > > > I'm liking the direction this is taking. However, I would still
> > > > like to have a clearer and feasible plan that would work for
> > > > -device, -machine, and -cpu.
> > >
> > >
On 02/12/20 13:51, Eduardo Habkost wrote:
I'm liking the direction this is taking. However, I would still
like to have a clearer and feasible plan that would work for
-device, -machine, and -cpu.
-cpu is not a problem since it's generally created with a static
configuration (now done with
On Wed, Dec 02, 2020 at 10:30:11AM +0100, Paolo Bonzini wrote:
> On 01/12/20 23:08, Eduardo Habkost wrote:
> > > Properties are only a useful concept if they have a use. If
> > > -object/object_add/object-add can do the same job without properties,
> > > properties are not needed anymore.
> >
>
On 02/12/20 11:27, Kevin Wolf wrote:
Declaring read-only QOM properties is trivial.
Trivial sounds like it's something the computer should be doing.
Possibly, but not necessarily. There's always a cost to automatic code
generation. If things are _too_ trivial and easy to get right, the
On 02/12/20 11:38, Kevin Wolf wrote:
Am 02.12.2020 um 10:30 hat Paolo Bonzini geschrieben:
On 01/12/20 23:08, Eduardo Habkost wrote:
Properties are only a useful concept if they have a use. If
-object/object_add/object-add can do the same job without properties,
properties are not needed
Am 02.12.2020 um 10:30 hat Paolo Bonzini geschrieben:
> On 01/12/20 23:08, Eduardo Habkost wrote:
> > > Properties are only a useful concept if they have a use. If
> > > -object/object_add/object-add can do the same job without properties,
> > > properties are not needed anymore.
> >
> > Do you
Am 01.12.2020 um 22:23 hat Paolo Bonzini geschrieben:
> On 01/12/20 20:35, Kevin Wolf wrote:
> > Am 01.12.2020 um 18:16 hat Paolo Bonzini geschrieben:
> > I don't think this is actually a new things. We already have types and
> > commands declared with things like 'if': 'defined(TARGET_S390X)'.
>
On 01/12/20 23:08, Eduardo Habkost wrote:
Properties are only a useful concept if they have a use. If
-object/object_add/object-add can do the same job without properties,
properties are not needed anymore.
Do you mean "not needed for -object anymore"? Properties are
still used by internal C
On Tue, Dec 01, 2020 at 10:23:57PM +0100, Paolo Bonzini wrote:
> On 01/12/20 20:35, Kevin Wolf wrote:
> > Am 01.12.2020 um 18:16 hat Paolo Bonzini geschrieben:
> > I don't think this is actually a new things. We already have types and
> > commands declared with things like 'if':
On 01/12/20 20:35, Kevin Wolf wrote:
Am 01.12.2020 um 18:16 hat Paolo Bonzini geschrieben:
I don't think this is actually a new things. We already have types and
commands declared with things like 'if': 'defined(TARGET_S390X)'.
As far as I understand, QAPI generated files are already built per
Am 01.12.2020 um 18:16 hat Paolo Bonzini geschrieben:
> On 01/12/20 17:20, Kevin Wolf wrote:
> > Am 30.11.2020 um 20:35 hat Paolo Bonzini geschrieben:
> > > For devices it's just the practical issue that there are too many to have
> > > something like this series. For machine types the main issue
On Tue, Dec 01, 2020 at 06:16:14PM +0100, Paolo Bonzini wrote:
> On 01/12/20 17:20, Kevin Wolf wrote:
[...]
> > BlockdevOptions is about external interfaces, not about
> > implementation details. Same thing as QOM properties are external
> > interfaces, not implementation details. There may be
On 01/12/20 17:20, Kevin Wolf wrote:
Am 30.11.2020 um 20:35 hat Paolo Bonzini geschrieben:
For devices it's just the practical issue that there are too many to have
something like this series. For machine types the main issue is that the
version-specific machine types would have to be defined
Am 30.11.2020 um 20:35 hat Paolo Bonzini geschrieben:
> On 30/11/20 19:10, Kevin Wolf wrote:
> > Am 30.11.2020 um 17:57 hat Paolo Bonzini geschrieben:
> > > The main problem is that it wouldn't extend well, if at all, to
> > > machines and devices. So those would still not be integrated into the
Paolo Bonzini writes:
> On 30/11/20 16:30, Daniel P. Berrangé wrote:
>> { 'struct': 'QCryptoSecretCommon',
>>'base': 'Object',
>>'state': { 'rawdata': '*uint8_t',
>> 'rawlen': 'size_t' },
>>'data': { '*format': 'QCryptoSecretFormat',
>> '*keyid': 'str',
>>
On 30/11/20 19:10, Kevin Wolf wrote:
Am 30.11.2020 um 17:57 hat Paolo Bonzini geschrieben:
The main problem is that it wouldn't extend well, if at all, to
machines and devices. So those would still not be integrated into the
QAPI schema.
What do you think is the biggest difference there?
On Mon, Nov 30, 2020 at 13:25:20 +0100, Kevin Wolf wrote:
> This series adds a QAPI type for the properties of all user creatable
> QOM types and finally makes QMP object-add use the new ObjectOptions
> union so that QAPI introspection can be used for user creatable objects.
FYI, here's a libvirt
Am 30.11.2020 um 17:57 hat Paolo Bonzini geschrieben:
> On 30/11/20 16:46, Kevin Wolf wrote:
> > Am 30.11.2020 um 15:58 hat Paolo Bonzini geschrieben:
> > > With this series it's basically pointless to have QOM properties at
> > > all.
> >
> > Not entirely, because there are still some writable
On 30/11/20 16:46, Kevin Wolf wrote:
Am 30.11.2020 um 15:58 hat Paolo Bonzini geschrieben:
With this series it's basically pointless to have QOM properties at
all.
Not entirely, because there are still some writable properties that can
be changed later on.
Are there really any (that are not
On Mon, Nov 30, 2020 at 05:13:57PM +0100, Kevin Wolf wrote:
> Am 30.11.2020 um 16:30 hat Daniel P. Berrangé geschrieben:
> > On Mon, Nov 30, 2020 at 03:58:23PM +0100, Paolo Bonzini wrote:
> > > On 30/11/20 13:25, Kevin Wolf wrote:
> > > > This series adds a QAPI type for the properties of all
On 30/11/20 16:30, Daniel P. Berrangé wrote:
{ 'struct': 'QCryptoSecretCommon',
'base': 'Object',
'state': { 'rawdata': '*uint8_t',
'rawlen': 'size_t' },
'data': { '*format': 'QCryptoSecretFormat',
'*keyid': 'str',
'*iv': 'str' } }
{ 'struct':
Am 30.11.2020 um 16:30 hat Daniel P. Berrangé geschrieben:
> On Mon, Nov 30, 2020 at 03:58:23PM +0100, Paolo Bonzini wrote:
> > On 30/11/20 13:25, Kevin Wolf wrote:
> > > This series adds a QAPI type for the properties of all user creatable
> > > QOM types and finally makes QMP object-add use the
Am 30.11.2020 um 15:58 hat Paolo Bonzini geschrieben:
> On 30/11/20 13:25, Kevin Wolf wrote:
> > This series adds a QAPI type for the properties of all user creatable
> > QOM types and finally makes QMP object-add use the new ObjectOptions
> > union so that QAPI introspection can be used for user
On Mon, Nov 30, 2020 at 03:58:23PM +0100, Paolo Bonzini wrote:
> On 30/11/20 13:25, Kevin Wolf wrote:
> > This series adds a QAPI type for the properties of all user creatable
> > QOM types and finally makes QMP object-add use the new ObjectOptions
> > union so that QAPI introspection can be used
On 30/11/20 13:25, Kevin Wolf wrote:
This series adds a QAPI type for the properties of all user creatable
QOM types and finally makes QMP object-add use the new ObjectOptions
union so that QAPI introspection can be used for user creatable objects.
After this series, there is least one obvious
39 matches
Mail list logo
