On 12/16/2011 06:53 PM, Max Filippov wrote:
git bisect says this. I didn't believe it first time, so I ran it
twice with a few modifications, and it pointed to the same commit both
times ...
Richard,
could you please elaborate on your testcase and configuration
(host/target architecture, comma
On 12/16/2011 06:07 PM, Richard W.M. Jones wrote:
git bisect says this. I didn't believe it first time, so I ran it
twice with a few modifications, and it pointed to the same commit both
times ...
67882fd177389527510eb36b3f7712011a835545 is the first bad commit
commit 67882fd177389527510eb36b3
On 12/16/2011 06:07 PM, Richard W.M. Jones wrote:
git bisect says this. I didn't believe it first time, so I ran it
twice with a few modifications, and it pointed to the same commit both
times ...
Need more details because it doesn't appear to be broken to me.
What guest, what's your command
>> git bisect says this. I didn't believe it first time, so I ran it
>> twice with a few modifications, and it pointed to the same commit both
>> times ...
>
> Richard,
> could you please elaborate on your testcase and configuration
> (host/target architecture, command lines, etc).
Ok, I've found
On 16 December 2011 18:50, Sebastian Huber
wrote:
> According to "ARMv7-M Architecture Reference Manual" issue D section
> "B3.2.10 System Handler Prioriy Register 1, SHPR1", "B3.2.11 System
> Handler Prioriy Register 2, SHPR2", and "B3.2.12 System Handler Prioriy
> Register 3, SHPR3".
This would
> git bisect says this. I didn't believe it first time, so I ran it
> twice with a few modifications, and it pointed to the same commit both
> times ...
Richard,
could you please elaborate on your testcase and configuration
(host/target architecture, command lines, etc).
> 67882fd177389527510eb3
git bisect says this. I didn't believe it first time, so I ran it
twice with a few modifications, and it pointed to the same commit both
times ...
67882fd177389527510eb36b3f7712011a835545 is the first bad commit
commit 67882fd177389527510eb36b3f7712011a835545
Author: Max Filippov
Date: Tue Se
Am 16.12.2011 04:24, schrieb TeLeMan:
On Sun, Dec 4, 2011 at 05:32, Stefan Weil wrote:
Since commit 1d14ffa97eacd3cb722271eaf6f093038396eac4 (in 2005),
QEMU applications on W32 don't use the default SDL compiler flags:
Instead of a GUI application, a console application is created.
This has d
Expose only one container MemoryRegion to sysbus.
(Peter Maydell's idea)
Signed-off-by: Benoît Canet
---
hw/ppce500_pci.c | 27 ++-
1 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index 6232af1..b606206 100644
--- a/hw
The isa region is not exposed as a sysbus region because the iobr
register contains its address and use it to remap dynamically
the region. (Peter Maydell's idea)
Signed-off-by: Benoît Canet
---
hw/r2d.c| 14 --
hw/sh_pci.c | 29 -
2 files changed,
This function is not longer in use so remove it.
Signed-off-by: Benoît Canet
---
hw/sysbus.c | 16
hw/sysbus.h |5 -
2 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/hw/sysbus.c b/hw/sysbus.c
index b315a8c..81a57bd 100644
--- a/hw/sysbus.c
+++ b/hw/sysbu
These patches remove sysbus_init_mmio_cb2 usage from the codebase.
v2:
dont't change ppce500 initialisation method (peter)
v3:
remove unused variable (anthony)
Benoît Canet (3):
sh_pci: remove sysbus_init_mmio_cb2 usage
ppce500_pci: remove sysbus_init_mmio_cb2 usage
sysbus: remove sysbus_in
(something seems odd - I only got Andreas' reply, not the original mail)
On 16.12.2011, at 21:06, Andreas Färber wrote:
> Am 16.12.2011 19:08, schrieb Anthony Liguori:
>> I notice that these two machines have seem to have never really been touched
>> other than tree-wide refactoring since their i
On Fri, Sep 30, 2011 at 05:51:52PM +0100, Richard W.M. Jones wrote:
> On Fri, Sep 30, 2011 at 02:11:48PM +0100, Richard W.M. Jones wrote:
> >
> > I've not looked into this at all, it's just a report that something
> > seems to be "up". I will try to git bisect this later if no one spots
> > anyth
On Fri, Dec 09, 2011 at 08:20:16PM -, Michael Roth wrote:
> On 12/09/2011 01:39 PM, Vagrant Cascadian wrote:
> >
> > /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o):
> > In function `g_get_any_init_do':
> >(.text+0xbbb): warning: Using 'getpwuid_r' in st
Salve,
vorrei cogliere questa occasione per presentarmi.
Il mio nome è Andrea e sono la responsabile di Migliorewebsites.com
Lavoro al fianco di numerosi siti internet. Gestisco il loro SEO in base alle
particolarità
dei maggiori motori di ricerca on line, tra cui Google, Bing e Yahoo.
Lavorand
When migrating a vm using vhost-net we hit the following assertion:
qemu-kvm: /usr/src/packages/BUILD/qemu-kvm-0.15.1/hw/vhost.c:30:
vhost_dev_sync_region: Assertion `start / (0x1000 * (8 *
sizeof(vhost_log_chunk_t))) < dev->log_size' failed.
The cases which the end < start check is intended to c
Am 16.12.2011 19:08, schrieb Anthony Liguori:
> I notice that these two machines have seem to have never really been touched
> other than tree-wide refactoring since their introduction. Googling for the
> machine types doesn't hit any user questions or comments about the machine
> types.
>
> For
Hello,
this may help to fix Bug 696094.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese N
This is unused for the ARMv7-M NVIC.
Signed-off-by: Sebastian Huber
---
hw/arm_gic.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index 5139d95..cafcc81 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -707,7 +707,11 @@ static void gic_re
Hello,
I am able to run the RTEMS real time system on the TI Stellaris LM3S6965
with a working system tick. I used the attached local hacks and patches
with the Qemu development branch from today.
Have a nice day!
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-8217
According to "ARMv7-M Architecture Reference Manual" issue D section
"B3.2.10 System Handler Prioriy Register 1, SHPR1", "B3.2.11 System
Handler Prioriy Register 2, SHPR2", and "B3.2.12 System Handler Prioriy
Register 3, SHPR3".
Signed-off-by: Sebastian Huber
---
hw/arm_gic.c | 16
Signed-off-by: Paolo Bonzini
---
hw/qdev-properties.c | 39 ---
hw/qdev.c|3 +--
hw/qdev.h|2 ++
3 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index f0b811c..76ecb3
Signed-off-by: Paolo Bonzini
---
hw/qdev-properties.c | 12
hw/qdev.c|9 ++---
hw/qdev.h|1 +
3 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index f7aa3cb..dd41e5a 100644
--- a/hw/qdev-
This patch adds a visitor interface to Property. This way, QOM will be
able to expose Properties that access a fixed field in a struct without
exposing also the everything-is-a-string "feature" of qdev properties.
Whenever the printed representation in both QOM and qdev (which is
typically the ca
On 12/16/2011 06:00 PM, Anthony Liguori wrote:
And perhaps it would make more sense to return Error * and make the
function name be a constructor:
Error *error_from_qdev_prop_err(int ret, DeviceState *dev,
Property *prop, const char *value);
That doesn't work
This will be used when reject invalid values for integer fields that
are less than 64-bits wide.
Signed-off-by: Paolo Bonzini
---
qerror.c |5 +
qerror.h |3 +++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index adde8a5..9a75d06 100644
--- a/qer
Push legacy properties into a legacy<...> namespace, and make them
available with correct types too.
Signed-off-by: Paolo Bonzini
---
hw/qdev.c | 28 +---
hw/qdev.h |7 +++
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
ind
QOM right now does not have a way to communicate values for qdev
properties except as strings. This is bad.
This patch improves the Property implementation so that properties
export a visitor-based interface in addition to the string-based
interface. The new interface can then be registered as a
On 12/16/2011 10:47 AM, Paolo Bonzini wrote:
Push legacy properties into a legacy<...> namespace, and make them
available with correct types too.
Signed-off-by: Paolo Bonzini
---
hw/qdev.c | 28 +---
hw/qdev.h |7 +++
2 files changed, 28 insertions(+), 7 de
On 12/16/2011 10:47 AM, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
---
hw/qdev-properties.c | 12
hw/qdev.c|9 ++---
hw/qdev.h|1 +
3 files changed, 15 insertions(+), 7 dele
On 12/16/2011 10:47 AM, Paolo Bonzini wrote:
This patch adds a visitor interface to Property. This way, QOM will be
able to expose Properties that access a fixed field in a struct without
exposing also the everything-is-a-string "feature" of qdev properties.
Whenever the printed representation
On 12/16/2011 11:00 AM, Paolo Bonzini wrote:
On 12/16/2011 03:01 PM, Paolo Bonzini wrote:
I'd rather use generic errors when possible. How about
VALUE_OUT_OF_RANGE and we can make the message "'%(item)' doesn't take
value..." and pass "%s.%s" % (device, property) for item.
Ok.
I didn't do t
On 12/16/2011 10:47 AM, Paolo Bonzini wrote:
This will be used when reject invalid values for integer fields that
are less than 64-bits wide.
Signed-off-by: Paolo Bonzini
VALUE_OUT_OF_RANGE?
Regards,
Anthony Liguori
---
qerror.c |5 +
qerror.h |3 +++
2 files changed, 8 ins
On 12/16/2011 03:01 PM, Paolo Bonzini wrote:
I'd rather use generic errors when possible. How about
VALUE_OUT_OF_RANGE and we can make the message "'%(item)' doesn't take
value..." and pass "%s.%s" % (device, property) for item.
Ok.
I didn't do this in the end for two reasons.
First, that
On 12/16/2011 10:47 AM, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini
---
hw/qdev-properties.c | 39 ---
hw/qdev.c|3 +--
hw/qdev.h|2 ++
3 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/hw/qdev-propert
qdev_property_get and qdev_property_set can generate permission
denied errors themselves. Do not duplicate this functionality in
qdev_get/set_legacy_property, and clean up excessive indentation.
Reviewed-by: Anthony Liguori
Signed-off-by: Paolo Bonzini
---
hw/qdev.c | 46 +++-
A NULL qobj can occur when a parameter is fetched via qdict_get, but
the parameter is not in the command. By returning NULL, the caller can
choose whether to raise a missing parameter error, an invalid parameter
type error, or use a default value. For example, qom-set could can
use this to reset
Reviewed-by: Anthony Liguori
Signed-off-by: Paolo Bonzini
---
hw/qdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 83913c7..bda8d6c 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1110,7 +1110,7 @@ void qdev_property_set(DeviceState *dev, Vis
Hi,
>> What are the uses of null in qdev string properties? I know you can't
>> set a string to null since parse() doesn't have a null syntax. So we're
>> really just talking about an uninitialized state, right?
>
> Yes. No ROM BAR is an example of a NULL string property.
Both NULL and zero
On 12/16/2011 04:54 PM, Anthony Liguori wrote:
On 12/16/2011 09:42 AM, Paolo Bonzini wrote:
On 12/16/2011 04:23 PM, Anthony Liguori wrote:
Ok. I think nullable strings are not a good idea simply because it
means that a property can have a state that cannot be set.
How is this different from N
On 12/16/2011 09:42 AM, Paolo Bonzini wrote:
On 12/16/2011 04:23 PM, Anthony Liguori wrote:
Ok. I think nullable strings are not a good idea simply because it
means that a property can have a state that cannot be set.
How is this different from NULL links? (Honest, not trick question :)).
An
On 12/16/2011 04:23 PM, Anthony Liguori wrote:
Ok. I think nullable strings are not a good idea simply because it
means that a property can have a state that cannot be set.
How is this different from NULL links? (Honest, not trick question :)).
Long term, I want to be able to do something l
On 12/16/2011 09:13 AM, Paolo Bonzini wrote:
On 12/16/2011 04:05 PM, Anthony Liguori wrote:
What are the uses of null in qdev string properties? I know you can't
set a string to null since parse() doesn't have a null syntax. So we're
really just talking about an uninitialized state, right?
On 12/16/2011 04:05 PM, Anthony Liguori wrote:
What are the uses of null in qdev string properties? I know you can't
set a string to null since parse() doesn't have a null syntax. So we're
really just talking about an uninitialized state, right?
Yes. No ROM BAR is an example of a NULL string
Am 16.12.2011 15:54, schrieb Anthony Liguori:
> On 12/16/2011 08:18 AM, Kevin Wolf wrote:
>> Am 16.12.2011 14:51, schrieb Anthony Liguori:
>>> What I would like to get to eventually is:
>>>
>>> struct ISASerial {
>>> Device parent;
>>>
>>> UART _child uart;
>>> ISABus _link *bus;
>>>
On 12/16/2011 09:03 AM, Paolo Bonzini wrote:
On 12/16/2011 03:56 PM, Anthony Liguori wrote:
I'd really prefer to stick to non-nullable strings as there is no
obvious way to specify NULL in command line options.
We can leave it as the default. A property with a non-null default is implicitly
no
On 12/16/2011 03:56 PM, Anthony Liguori wrote:
I'd really prefer to stick to non-nullable strings as there is no
obvious way to specify NULL in command line options.
We can leave it as the default. A property with a non-null default is
implicitly not nullable, which actually makes some sense.
On 12/16/2011 08:49 AM, Paolo Bonzini wrote:
On 12/16/2011 03:46 PM, Anthony Liguori wrote:
Hmm, then we have to introduce NULL into QJson and visitors.
Visitors assume that strings aren't nullable (which is actually true in
JSON and in QString).
I also think that string properties shouldn't
On 12/16/2011 03:54 PM, Anthony Liguori wrote:
Yes. I'm not terribly sure how this would work yet. A link and a child
property both acquire references to a device and release a reference to
a device at destruction time.
For a child property, the reference held by the parent is the only
refere
On 12/16/2011 08:18 AM, Kevin Wolf wrote:
Am 16.12.2011 14:51, schrieb Anthony Liguori:
On 12/16/2011 06:24 AM, Paolo Bonzini wrote:
On 12/16/2011 11:36 AM, Kevin Wolf wrote:
I think actually this is not the biggest problem. child properties are
dynamic, and it's not a problem IMO if they are
On Thu, Dec 15, 2011 at 11:05:07AM -0700, Alex Williamson wrote:
> Starting with it in the core and hand waving some future use that we
> don't plan to implement right now seems like the wrong direction.
I agree with Alex. First of all, I havn't seen any real vfio problem
that can't be solved with
On 12/16/2011 03:46 PM, Anthony Liguori wrote:
Hmm, then we have to introduce NULL into QJson and visitors.
Visitors assume that strings aren't nullable (which is actually true in
JSON and in QString).
I also think that string properties shouldn't be nullable.
Unfortunately, qdev string pro
On 12/16/2011 08:22 AM, Paolo Bonzini wrote:
On 12/16/2011 03:10 PM, Anthony Liguori wrote:
If a property function does not set the Error pointer, it must visit
something.
Hmm, then we have to introduce NULL into QJson and visitors.
Visitors assume that strings aren't nullable (which is actu
On 12/16/2011 08:18 AM, Paolo Bonzini wrote:
On 12/16/2011 03:05 PM, Anthony Liguori wrote:
I thought the same initially. However, I noticed that the visitor
interfaces for
links is also a string. So, even if a block/char/netdev property later
becomes a
link<>, the interface would not change.
On 12/16/2011 08:18 AM, Paolo Bonzini wrote:
On 12/16/2011 03:06 PM, Anthony Liguori wrote:
- type = g_strdup_printf("legacy<%s>", prop->info->name);
+ type = g_strdup_printf("legacy<%s>",
+ prop->info->legacy_name ?: prop->info->name);
I think this confuses the legacy type with the legacy pr
On 12/16/2011 03:10 PM, Anthony Liguori wrote:
If a property function does not set the Error pointer, it must visit
something.
Hmm, then we have to introduce NULL into QJson and visitors.
Paolo
On 12/16/2011 03:06 PM, Anthony Liguori wrote:
-type = g_strdup_printf("legacy<%s>", prop->info->name);
+type = g_strdup_printf("legacy<%s>",
+ prop->info->legacy_name ?: prop->info->name);
I think this confuses the legacy type with the legacy property names.
On 12/16/2011 03:05 PM, Anthony Liguori wrote:
I thought the same initially. However, I noticed that the visitor
interfaces for
links is also a string. So, even if a block/char/netdev property later
becomes a
link<>, the interface would not change.
The semantics change though. A "drive" link
Am 16.12.2011 14:51, schrieb Anthony Liguori:
> On 12/16/2011 06:24 AM, Paolo Bonzini wrote:
>> On 12/16/2011 11:36 AM, Kevin Wolf wrote:
I think actually this is not the biggest problem. child properties are
dynamic, and it's not a problem IMO if they are created like that.
>>>
>>> That
On 12/16/2011 07:52 AM, Paolo Bonzini wrote:
On 12/16/2011 02:51 PM, Anthony Liguori wrote:
struct ISASerial {
Device parent;
UART _child uart;
ISABus _link *bus;
};
A child should be able to be part of the parent devices memory with its
life cycle bound to the parents life cycle. This is why
On 12/16/2011 08:00 AM, Paolo Bonzini wrote:
On 12/16/2011 02:55 PM, Anthony Liguori wrote:
This is visible with
qom-get path=/i440fx/piix3 property=romfile
after static non-string properties are introduced.
I'm a bit confused about what's happening here. What's the significance
of non-strin
On 12/16/2011 06:01 AM, Paolo Bonzini wrote:
For non-string properties, there is no reason to distinguish type names
such as "uint32" or "hex32". Restrict those to legacy properties.
Signed-off-by: Paolo Bonzini
---
hw/qdev-properties.c | 12
hw/qdev.c|9 ++
On 12/16/2011 07:51 AM, Paolo Bonzini wrote:
On 12/16/2011 02:11 PM, Gerd Hoffmann wrote:
I think we should not touch these. First it doesn't buy us much as we
are using the old parse/print functions for the visitor-based access,
which doesn't look like a good idea to me. Also they will not stay
Add the piix3 child also in the Xen case. Drop the unused piix3
field from PCII440FXState.
Signed-off-by: Paolo Bonzini
---
hw/piix_pci.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index d785d4b..8d106a8 100644
--- a/hw/piix_pci
On 12/16/2011 03:00 PM, Anthony Liguori wrote:
This will be used when reject invalid values for integer fields that
are less than 64-bits wide.
Signed-off-by: Paolo Bonzini
I'd rather use generic errors when possible. How about
VALUE_OUT_OF_RANGE and we can make the message "'%(item)' doesn't
On 12/16/2011 02:55 PM, Anthony Liguori wrote:
This is visible with
qom-get path=/i440fx/piix3 property=romfile
after static non-string properties are introduced.
I'm a bit confused about what's happening here. What's the significance
of non-string properties?
Should have been "static
On 12/16/2011 06:01 AM, Paolo Bonzini wrote:
This will be used when reject invalid values for integer fields that
are less than 64-bits wide.
Signed-off-by: Paolo Bonzini
I'd rather use generic errors when possible. How about VALUE_OUT_OF_RANGE and
we can make the message "'%(item)' doesn't
On 12/16/2011 06:01 AM, Paolo Bonzini wrote:
qdev_property_get and qdev_property_set can generate permission
denied errors themselves. Do not duplicate this functionality in
qdev_get/set_legacy_property, and clean up excessive indentation.
Signed-off-by: Paolo Bonzini
Nice cleanup.
Reviewed-
On 12/16/2011 06:01 AM, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini
Yeah, this code path is currently dead as there is no way to test it until we
defer s/init/realize/ and defer it to guest launch.
In my next series when I introduce Object and move properties into it, we can
write som
On 12/16/2011 06:01 AM, Paolo Bonzini wrote:
A NULL qobj can occur when a parameter is fetched via qdict_get, but
the parameter is not in the command. By returning NULL, the caller can
choose whether to raise a missing parameter error, an invalid parameter
type error, or use a default value. Fo
On 12/16/2011 06:01 AM, Paolo Bonzini wrote:
QAPI currently cannot deal with no object pushed to the stack,
and dereferences a NULL pointer. This is visible with
qom-get path=/i440fx/piix3 property=romfile
after static non-string properties are introduced.
I'm a bit confused about what'
On 12/16/2011 06:01 AM, Paolo Bonzini wrote:
QOM right now does not have a way to communicate values for qdev
properties except as strings. This is bad.
This patch improves the Property implementation so that properties
export a visitor-based interface in addition to the string-based
interface.
On 12/16/2011 02:51 PM, Anthony Liguori wrote:
struct ISASerial {
Device parent;
UART _child uart;
ISABus _link *bus;
};
A child should be able to be part of the parent devices memory with its
life cycle bound to the parents life cycle. This is why a child
property shouldn't be nul
On 12/16/2011 07:28 AM, Paolo Bonzini wrote:
On 12/16/2011 01:55 PM, Kevin Wolf wrote:
I don't think that not remembering the child device because you don't
need to reference it any more makes it any less static. You could easily
add the struct member, assign it once and then it matches your
def
On 12/16/2011 06:24 AM, Paolo Bonzini wrote:
On 12/16/2011 11:36 AM, Kevin Wolf wrote:
> I think actually this is not the biggest problem. child properties are
> dynamic, and it's not a problem IMO if they are created like that.
That they are added in an init function is an indicator that they
On 12/16/2011 02:11 PM, Gerd Hoffmann wrote:
I think we should not touch these. First it doesn't buy us much as we
are using the old parse/print functions for the visitor-based access,
which doesn't look like a good idea to me. Also they will not stay but
will be converted to child<> and link<
On 12/16/2011 04:17 AM, Paolo Bonzini wrote:
On 12/16/2011 10:42 AM, Kevin Wolf wrote:
>
> Applied.
>
> Regards,
>
> Anthony Liguori
So you pushed this with qdev_property_add_child() calls spread all over
the place instead of being treated like other properties?:-(
I think actually this is no
On 12/16/2011 03:42 AM, Kevin Wolf wrote:
Am 15.12.2011 19:10, schrieb Anthony Liguori:
On 12/12/2011 02:29 PM, Anthony Liguori wrote:
This is a follow up to my previous series to get us started in the QOM
direction. A few things are different this time around. Most notably:
1) Devices no
On 12/16/2011 01:55 PM, Kevin Wolf wrote:
I don't think that not remembering the child device because you don't
need to reference it any more makes it any less static. You could easily
add the struct member, assign it once and then it matches your
definition of static.
I think in that case you
Hi,
> PropertyInfo qdev_prop_drive = {
> .name = "drive",
> .type = PROP_TYPE_DRIVE,
> .size = sizeof(BlockDriverState *),
> .parse = parse_drive,
> .print = print_drive,
> +.get = get_generic,
> +.set = set_generic,
> .free = free_drive,
> };
>
Am 16.12.2011 13:24, schrieb Paolo Bonzini:
> On 12/16/2011 11:36 AM, Kevin Wolf wrote:
>>> I think actually this is not the biggest problem. child properties are
>>> dynamic, and it's not a problem IMO if they are created like that.
>>
>> That they are added in an init function is an indicator
This patch adds a visitor interface to Property. This way, QOM will be
able to expose Properties that access a fixed field in a struct without
exposing also the everything-is-a-string "feature" of qdev properties.
Whenever the printed representation in both QOM and qdev (which is
typically the ca
This will be used when reject invalid values for integer fields that
are less than 64-bits wide.
Signed-off-by: Paolo Bonzini
---
qerror.c |5 +
qerror.h |3 +++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index adde8a5..9a75d06 100644
--- a/qer
Push legacy properties into a legacy<...> namespace, and make them
available with correct types too.
Signed-off-by: Paolo Bonzini
---
hw/qdev.c | 28 +---
hw/qdev.h |7 +++
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
ind
A NULL qobj can occur when a parameter is fetched via qdict_get, but
the parameter is not in the command. By returning NULL, the caller can
choose whether to raise a missing parameter error, an invalid parameter
type error, or use a default value. For example, qom-set could can
use this to reset
qdev_property_get and qdev_property_set can generate permission
denied errors themselves. Do not duplicate this functionality in
qdev_get/set_legacy_property, and clean up excessive indentation.
Signed-off-by: Paolo Bonzini
---
hw/qdev.c | 46 +++---
1
On 12/16/2011 11:36 AM, Kevin Wolf wrote:
> I think actually this is not the biggest problem. child properties are
> dynamic, and it's not a problem IMO if they are created like that.
That they are added in an init function is an indicator that they aren't
really dynamic.
That's true. Howe
QAPI currently cannot deal with no object pushed to the stack,
and dereferences a NULL pointer. This is visible with
qom-get path=/i440fx/piix3 property=romfile
after static non-string properties are introduced.
Signed-off-by: Paolo Bonzini
---
qapi/qmp-output-visitor.c |4 ++--
1 fil
QOM right now does not have a way to communicate values for qdev
properties except as strings. This is bad.
This patch improves the Property implementation so that properties
export a visitor-based interface in addition to the string-based
interface. The new interface can then be registered as a
For non-string properties, there is no reason to distinguish type names
such as "uint32" or "hex32". Restrict those to legacy properties.
Signed-off-by: Paolo Bonzini
---
hw/qdev-properties.c | 12
hw/qdev.c|9 ++---
hw/qdev.h|1 +
3 files chan
Signed-off-by: Paolo Bonzini
---
hw/qdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 83913c7..bda8d6c 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -1110,7 +1110,7 @@ void qdev_property_set(DeviceState *dev, Visitor *v,
const char *name,
This patch removes support for parsing /proc/bus/usb/devices for device
discovery. The code lacks a few features compared to the sysfs code and
is also bitrotting as everybody has sysfs these days.
This implies having sysfs mounted is mandatory now to use the usb-host
driver. udev isn't required
On Fri, Dec 16, 2011 at 11:20:20AM +1100, Michael Ellerman wrote:
> It's a little unfriendly to call abort() without printing any sort of
> error message. So turn the DPRINTK() into an fprintf(stderr, ...).
>
> Signed-off-by: Michael Ellerman
> ---
> kvm-all.c |3 ++-
> 1 files changed, 2 in
On Thu, Dec 15, 2011 at 06:58:26PM +, Peter Maydell wrote:
> Calculate the system clock period on reset; otherwise it remains
> set to the default value of zero and attempting to use it provokes
> a hang. This is one of the issues noted in LP:696094.
>
> Signed-off-by: Peter Maydell
> ---
>
On Thu, Dec 15, 2011 at 06:28:52PM +, Peter Maydell wrote:
> Remove some dependency rules which aren't necessary (the automatically
> generated .d files cover all these). These were leftovers from dyngen
> days, when the object files also had a dependency on some generated
> files.
>
> Signed-
Am 16.12.2011 11:17, schrieb Paolo Bonzini:
> On 12/16/2011 10:42 AM, Kevin Wolf wrote:
Applied.
Regards,
Anthony Liguori
>> So you pushed this with qdev_property_add_child() calls spread all over
>> the place instead of being treated like other properties?:-(
>
>
On Thursday 15 December 2011 18:33:33 Ian Jackson wrote:
> Wei Wang2 writes ("[Xen-devel] [PATCH] xen-qemu: register virtual iommu
device on qemu pci bus"):
> > Attached patch is for qemu to register iommu device on pci bus. Guest OS
> > requires this to access iommu pci config space in some cases
On 12/16/2011 10:41 AM, Daniel P. Berrange wrote:
Yes& no. In general you are correct that g_malloc/g_strdup needs to
be matched with g_free, but in the context of the QEMU binary at least
we don't strictly need that.
The general issue is that GLib's memory allocators default to the
system mall
On 12/16/2011 10:42 AM, Kevin Wolf wrote:
>
> Applied.
>
> Regards,
>
> Anthony Liguori
So you pushed this with qdev_property_add_child() calls spread all over
the place instead of being treated like other properties?:-(
I think actually this is not the biggest problem. child properties ar
1 - 100 of 114 matches
Mail list logo
