On Thu, Nov 12, 2020 at 09:11:48AM +0100, Paolo Bonzini wrote:
> On 11/11/20 19:39, Eduardo Habkost wrote:
> > I will submit v3 of this series with both
> > object_class_property_add_field() and
> > object_class_add_field_properties() as internal QOM APIs.
> > object_class_add_field_properties()
On 11/11/20 19:39, Eduardo Habkost wrote:
I will submit v3 of this series with both
object_class_property_add_field() and
object_class_add_field_properties() as internal QOM APIs.
object_class_add_field_properties() will be used to implement
device_class_set_props().
I have no problem making
On Tue, Nov 10, 2020 at 11:38:04AM +0100, Kevin Wolf wrote:
> Am 09.11.2020 um 21:28 hat Eduardo Habkost geschrieben:
[...]
> > Anyway, If we are the only ones discussing this, I will just
> > defer to your suggestions as QOM maintainer. I hope we hear from
> > others.
>
> Well, I expressed my
On Tue, Nov 10, 2020 at 11:58:29AM +0100, Paolo Bonzini wrote:
> On 09/11/20 21:28, Eduardo Habkost wrote:
> > I don't know yet what's the best solution for the x86 feature
> > case. Maybe duplicating the list of feature names would be a
> > small price to pay to get a static list of properties
On 09/11/20 21:28, Eduardo Habkost wrote:
I don't know yet what's the best solution for the x86 feature
case. Maybe duplicating the list of feature names would be a
small price to pay to get a static list of properties defined at
compilation time? Maybe we can replace
Am 09.11.2020 um 21:28 hat Eduardo Habkost geschrieben:
> On Mon, Nov 09, 2020 at 08:27:21PM +0100, Paolo Bonzini wrote:
> > On 09/11/20 19:55, Eduardo Habkost wrote:
> > > On Mon, Nov 09, 2020 at 06:33:04PM +0100, Paolo Bonzini wrote:
> > > > On 09/11/20 18:16, Eduardo Habkost wrote:
> > > > > I
On Mon, Nov 09, 2020 at 08:27:21PM +0100, Paolo Bonzini wrote:
> On 09/11/20 19:55, Eduardo Habkost wrote:
> > On Mon, Nov 09, 2020 at 06:33:04PM +0100, Paolo Bonzini wrote:
> > > On 09/11/20 18:16, Eduardo Habkost wrote:
> > > > I mean extending the API to let custom setters and getters appear
>
On 09/11/20 19:55, Eduardo Habkost wrote:
On Mon, Nov 09, 2020 at 06:33:04PM +0100, Paolo Bonzini wrote:
On 09/11/20 18:16, Eduardo Habkost wrote:
I mean extending the API to let custom setters and getters appear
on the Property array, not using the existing API.
That seems like conflicting
On Mon, Nov 09, 2020 at 06:33:04PM +0100, Paolo Bonzini wrote:
> On 09/11/20 18:16, Eduardo Habkost wrote:
> > On Mon, Nov 09, 2020 at 05:34:01PM +0100, Paolo Bonzini wrote:
> > > On 09/11/20 16:21, Eduardo Habkost wrote:
> > > > Nothing prevents us from describing those properties inside the
> >
On 09/11/20 18:16, Eduardo Habkost wrote:
On Mon, Nov 09, 2020 at 05:34:01PM +0100, Paolo Bonzini wrote:
On 09/11/20 16:21, Eduardo Habkost wrote:
Nothing prevents us from describing those properties inside the
same property array.
Do you mean adding PropertyInfos for them? Adding a
On Mon, Nov 09, 2020 at 05:34:01PM +0100, Paolo Bonzini wrote:
> On 09/11/20 16:21, Eduardo Habkost wrote:
> > On Mon, Nov 09, 2020 at 03:15:26PM +0100, Paolo Bonzini wrote:
> > > On 09/11/20 12:34, Kevin Wolf wrote:
> > > > > If all properties were like this, it would be okay. But the API in
>
On 09/11/20 16:21, Eduardo Habkost wrote:
On Mon, Nov 09, 2020 at 03:15:26PM +0100, Paolo Bonzini wrote:
On 09/11/20 12:34, Kevin Wolf wrote:
If all properties were like this, it would be okay. But the API in v2 is
the one that is most consistent with QOM in general. Here is how this change
On Mon, Nov 09, 2020 at 03:15:26PM +0100, Paolo Bonzini wrote:
> On 09/11/20 12:34, Kevin Wolf wrote:
> > > If all properties were like this, it would be okay. But the API in v2 is
> > > the one that is most consistent with QOM in general. Here is how this
> > > change
> > > would be a loss in
On 09/11/20 12:34, Kevin Wolf wrote:
If all properties were like this, it would be okay. But the API in v2 is
the one that is most consistent with QOM in general. Here is how this change
would be a loss in term of consistency:
- you have the field properties split in two (with the property
Am 08.11.2020 um 15:05 hat Paolo Bonzini geschrieben:
> On 06/11/20 22:10, Eduardo Habkost wrote:
> > This was implemented at:
> > https://gitlab.com/ehabkost/qemu/-/commits/work/qdev-make-generic
> >
> > This is the interface I'd like to submit as v3:
> >
> > static Property machine_props[] = {
On 06/11/20 22:10, Eduardo Habkost wrote:
This was implemented at:
https://gitlab.com/ehabkost/qemu/-/commits/work/qdev-make-generic
This is the interface I'd like to submit as v3:
static Property machine_props[] = {
DEFINE_PROP_STRING("kernel", MachineState, kernel_filename,
On Fri, Nov 06, 2020 at 10:50:19AM -0500, Eduardo Habkost wrote:
> On Fri, Nov 06, 2020 at 10:45:11AM +0100, Kevin Wolf wrote:
> > Am 04.11.2020 um 16:59 hat Eduardo Habkost geschrieben:
> > > This series refactor the qdev property code so the static
> > > property system can be used by any QOM
On Fri, Nov 06, 2020 at 10:45:11AM +0100, Kevin Wolf wrote:
> Am 04.11.2020 um 16:59 hat Eduardo Habkost geschrieben:
> > This series refactor the qdev property code so the static
> > property system can be used by any QOM type. As an example, at
> > the end of the series some properties in
Am 04.11.2020 um 16:59 hat Eduardo Habkost geschrieben:
> This series refactor the qdev property code so the static
> property system can be used by any QOM type. As an example, at
> the end of the series some properties in TYPE_MACHINE are
> converted to static properties to demonstrate the new
static property API usable by any QOM type
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT
This series refactor the qdev property code so the static
property system can be used by any QOM type. As an example, at
the end of the series some properties in TYPE_MACHINE are
converted to static properties to demonstrate the new API.
Changes v1 -> v2
* Rename functions and
21 matches
Mail list logo
