On 28/06/17 15:12, Igor Mammedov wrote:
>>> I don't understand this part. When and why would the check become
>>> useless?
>>
>> Well because when using the standard QEMU pattern of
>> qdev_create()...qdev_init_nofail() it is possible to realize the device
>> and wire up its MemoryRegions manua
On Wed, 28 Jun 2017 16:21:40 +0200
Laszlo Ersek wrote:
> On 06/28/17 16:12, Igor Mammedov wrote:
> > On Wed, 28 Jun 2017 08:09:35 +0100
> > Mark Cave-Ayland wrote:
>
> >> 1) Alter fw_cfg_find() to use object_resolve_path_type("", TYPE_FW_CFG,
> >> NULL)
> > I'd make use of the 3rd argument
On 06/28/17 16:12, Igor Mammedov wrote:
> On Wed, 28 Jun 2017 08:09:35 +0100
> Mark Cave-Ayland wrote:
>> 1) Alter fw_cfg_find() to use object_resolve_path_type("", TYPE_FW_CFG,
>> NULL)
> I'd make use of the 3rd argument &ambiguous and assert on it
I vaguely recall playing with "ambiguous" in f
On Wed, 28 Jun 2017 08:09:35 +0100
Mark Cave-Ayland wrote:
> On 27/06/17 01:49, Eduardo Habkost wrote:
>
> > On Sun, Jun 25, 2017 at 07:58:04PM +0100, Mark Cave-Ayland wrote:
> >> On 23/06/17 19:50, Eduardo Habkost wrote:
> >>
> Really, please go back to the earlier discussion around fw
On 27/06/17 01:49, Eduardo Habkost wrote:
> On Sun, Jun 25, 2017 at 07:58:04PM +0100, Mark Cave-Ayland wrote:
>> On 23/06/17 19:50, Eduardo Habkost wrote:
>>
Really, please go back to the earlier discussion around fw_cfg_init1()
and you'll see my original point (which matches what you ju
On Sun, Jun 25, 2017 at 07:58:04PM +0100, Mark Cave-Ayland wrote:
> On 23/06/17 19:50, Eduardo Habkost wrote:
>
> >> Really, please go back to the earlier discussion around fw_cfg_init1()
> >> and you'll see my original point (which matches what you just voiced).
> >
> > Yep. I was just not sure
On 23/06/17 19:50, Eduardo Habkost wrote:
>> Really, please go back to the earlier discussion around fw_cfg_init1()
>> and you'll see my original point (which matches what you just voiced).
>
> Yep. I was just not sure validation on realize was necessary or
> convenient. It looks like we agree
On Fri, Jun 23, 2017 at 06:48:40PM +0200, Laszlo Ersek wrote:
> On 06/23/17 18:10, Eduardo Habkost wrote:
> > On Fri, Jun 23, 2017 at 05:52:03PM +0200, Laszlo Ersek wrote:
> >> On 06/23/17 13:50, Eduardo Habkost wrote:
> >>> On Fri, Jun 23, 2017 at 09:12:01AM +0100, Mark Cave-Ayland wrote:
> O
On 06/23/17 18:10, Eduardo Habkost wrote:
> On Fri, Jun 23, 2017 at 05:52:03PM +0200, Laszlo Ersek wrote:
>> On 06/23/17 13:50, Eduardo Habkost wrote:
>>> On Fri, Jun 23, 2017 at 09:12:01AM +0100, Mark Cave-Ayland wrote:
On 21/06/17 14:23, Eduardo Habkost wrote:
> I now have a v7
On Fri, Jun 23, 2017 at 05:52:03PM +0200, Laszlo Ersek wrote:
> On 06/23/17 13:50, Eduardo Habkost wrote:
> > On Fri, Jun 23, 2017 at 09:12:01AM +0100, Mark Cave-Ayland wrote:
> >> On 21/06/17 14:23, Eduardo Habkost wrote:
> >>
> >>> I now have a v7 patchset ready to go (currently hosted at
> >
On 06/23/17 13:50, Eduardo Habkost wrote:
> On Fri, Jun 23, 2017 at 09:12:01AM +0100, Mark Cave-Ayland wrote:
>> On 21/06/17 14:23, Eduardo Habkost wrote:
>>
>>> I now have a v7 patchset ready to go (currently hosted at
>>> https://github.com/mcayland/qemu/tree/fwcfg7 for the curious). Lasz
On Fri, Jun 23, 2017 at 09:12:01AM +0100, Mark Cave-Ayland wrote:
> On 21/06/17 14:23, Eduardo Habkost wrote:
>
> > I now have a v7 patchset ready to go (currently hosted at
> > https://github.com/mcayland/qemu/tree/fwcfg7 for the curious). Laszlo,
> > I've currently left off your Test
On 21/06/17 14:23, Eduardo Habkost wrote:
> I now have a v7 patchset ready to go (currently hosted at
> https://github.com/mcayland/qemu/tree/fwcfg7 for the curious). Laszlo,
> I've currently left off your Tested-by tag since I'm not sure it's still
> valid for less-than-trivial ch
On Wed, Jun 21, 2017 at 01:17:06PM +0100, Mark Cave-Ayland wrote:
> On 21/06/17 12:36, Eduardo Habkost wrote:
>
> > On Wed, Jun 21, 2017 at 09:48:16AM +0200, Laszlo Ersek wrote:
> >> On 06/21/17 08:58, Mark Cave-Ayland wrote:
> >>> On 19/06/17 23:43, Laszlo Ersek wrote:
> >>>
> It looks good
On 21/06/17 12:36, Eduardo Habkost wrote:
> On Wed, Jun 21, 2017 at 09:48:16AM +0200, Laszlo Ersek wrote:
>> On 06/21/17 08:58, Mark Cave-Ayland wrote:
>>> On 19/06/17 23:43, Laszlo Ersek wrote:
>>>
It looks good to me, but please await Eduardo's reply as well.
In particular, it sho
On Wed, Jun 21, 2017 at 09:48:16AM +0200, Laszlo Ersek wrote:
> On 06/21/17 08:58, Mark Cave-Ayland wrote:
> > On 19/06/17 23:43, Laszlo Ersek wrote:
> >
> >> It looks good to me, but please await Eduardo's reply as well.
> >>
> >> In particular, it should be confirmed that object_resolve_path_typ
On 06/21/17 08:58, Mark Cave-Ayland wrote:
> On 19/06/17 23:43, Laszlo Ersek wrote:
>
>> It looks good to me, but please await Eduardo's reply as well.
>>
>> In particular, it should be confirmed that object_resolve_path_type()
>> matches instances of *subclasses* as well (as I expect it would). Y
On 19/06/17 23:43, Laszlo Ersek wrote:
> It looks good to me, but please await Eduardo's reply as well.
>
> In particular, it should be confirmed that object_resolve_path_type()
> matches instances of *subclasses* as well (as I expect it would). Your
> test results confirm that; let's make sure i
On 06/19/17 20:49, Mark Cave-Ayland wrote:
> On 19/06/17 18:09, Laszlo Ersek wrote:
>
>>> What seems to happen is that calling object_property_add_child() only
>>> succeeds for the first instance and so a simple comparison is enough to
>>> determine that the device already exists at FW_CFG_PATH. O
On 19/06/17 18:09, Laszlo Ersek wrote:
>> What seems to happen is that calling object_property_add_child() only
>> succeeds for the first instance and so a simple comparison is enough to
>> determine that the device already exists at FW_CFG_PATH. Or is this a
>> fairly terrible (ab)use of the QOM
On 06/19/17 18:57, Mark Cave-Ayland wrote:
> On 19/06/17 15:28, Eduardo Habkost wrote:
>
>> On Mon, Jun 19, 2017 at 01:59:07PM +0100, Mark Cave-Ayland wrote:
>>> In preparation for calling fw_cfg_init1() during realize rather than during
>>> init, move the assert() checking for existing fw_cfg dev
On 19/06/17 15:28, Eduardo Habkost wrote:
> On Mon, Jun 19, 2017 at 01:59:07PM +0100, Mark Cave-Ayland wrote:
>> In preparation for calling fw_cfg_init1() during realize rather than during
>> init, move the assert() checking for existing fw_cfg devices and the linking
>> of the device to the machi
On 06/19/17 16:28, Eduardo Habkost wrote:
> On Mon, Jun 19, 2017 at 01:59:07PM +0100, Mark Cave-Ayland wrote:
>> In preparation for calling fw_cfg_init1() during realize rather than during
>> init, move the assert() checking for existing fw_cfg devices and the linking
>> of the device to the machin
On Mon, Jun 19, 2017 at 01:59:07PM +0100, Mark Cave-Ayland wrote:
> In preparation for calling fw_cfg_init1() during realize rather than during
> init, move the assert() checking for existing fw_cfg devices and the linking
> of the device to the machine with object_property_add_child() to a new
> f
In preparation for calling fw_cfg_init1() during realize rather than during
init, move the assert() checking for existing fw_cfg devices and the linking
of the device to the machine with object_property_add_child() to a new
fw_cfg instance_init() function.
This guarantees that we will still assert
25 matches
Mail list logo