On 12/10/2018 16:21, Igor Mammedov wrote:
> On Fri, 12 Oct 2018 10:45:41 +0200
> David Hildenbrand wrote:
>
>>>
>>> The correct order should be opposite to one that created a devices,
>>> i.e. unplug -> unrealize -> delete.
>>> Doing unplug stuff after device was unrealized looks outright wrong
>
On Fri, 12 Oct 2018 10:45:41 +0200
David Hildenbrand wrote:
> >
> > The correct order should be opposite to one that created a devices,
> > i.e. unplug -> unrealize -> delete.
> > Doing unplug stuff after device was unrealized looks outright wrong
> > (essentially device doesn't exists anymore e
>
> The correct order should be opposite to one that created a devices,
> i.e. unplug -> unrealize -> delete.
> Doing unplug stuff after device was unrealized looks outright wrong
> (essentially device doesn't exists anymore except memory where it's
> been located).
pre_plug -> realize -> plug
u
On Thu, 11 Oct 2018 10:50:13 +0200
David Hildenbrand wrote:
> On 08/10/2018 16:12, Igor Mammedov wrote:
> > On Mon, 8 Oct 2018 14:41:50 +0200
> > David Hildenbrand wrote:
> >
> >> On 08/10/2018 14:19, Igor Mammedov wrote:
> >>> On Mon, 8 Oct 2018 13:47:53 +0200
> >>> David Hildenbrand wrot
On 08/10/2018 16:12, Igor Mammedov wrote:
> On Mon, 8 Oct 2018 14:41:50 +0200
> David Hildenbrand wrote:
>
>> On 08/10/2018 14:19, Igor Mammedov wrote:
>>> On Mon, 8 Oct 2018 13:47:53 +0200
>>> David Hildenbrand wrote:
>>>
> That way using [2] and [1 - modulo it should match only concrete
On Mon, 8 Oct 2018 14:41:50 +0200
David Hildenbrand wrote:
> On 08/10/2018 14:19, Igor Mammedov wrote:
> > On Mon, 8 Oct 2018 13:47:53 +0200
> > David Hildenbrand wrote:
> >
> >>> That way using [2] and [1 - modulo it should match only concrete type]
> >>> machine would be able to override ho
On 08/10/2018 14:19, Igor Mammedov wrote:
> On Mon, 8 Oct 2018 13:47:53 +0200
> David Hildenbrand wrote:
>
>>> That way using [2] and [1 - modulo it should match only concrete type]
>>> machine would be able to override hotplug handlers for TYPE_VIRTIO_PMEM_PCI
>>> and explicitly call machine + p
On Mon, 8 Oct 2018 13:47:53 +0200
David Hildenbrand wrote:
> > That way using [2] and [1 - modulo it should match only concrete type]
> > machine would be able to override hotplug handlers for TYPE_VIRTIO_PMEM_PCI
> > and explicitly call machine + pci hotplug handlers in necessary order.
> >
> >
> That way using [2] and [1 - modulo it should match only concrete type]
> machine would be able to override hotplug handlers for TYPE_VIRTIO_PMEM_PCI
> and explicitly call machine + pci hotplug handlers in necessary order.
>
> flow would look like:
> [acpi|shcp|native pci-e eject]->
>
On 04/10/2018 17:59, Igor Mammedov wrote:
> On Wed, 3 Oct 2018 19:21:25 +0200
> David Hildenbrand wrote:
>
>> On 03/10/2018 08:29, David Gibson wrote:
>>> On Wed, Sep 26, 2018 at 11:42:13AM +0200, David Hildenbrand wrote:
The unplug and unplug_request handlers are special: They are not
>>>
On Wed, 3 Oct 2018 19:21:25 +0200
David Hildenbrand wrote:
> On 03/10/2018 08:29, David Gibson wrote:
> > On Wed, Sep 26, 2018 at 11:42:13AM +0200, David Hildenbrand wrote:
> >> The unplug and unplug_request handlers are special: They are not
> >> executed when unrealizing a device, but rather
On 03/10/2018 08:29, David Gibson wrote:
> On Wed, Sep 26, 2018 at 11:42:13AM +0200, David Hildenbrand wrote:
>> The unplug and unplug_request handlers are special: They are not
>> executed when unrealizing a device, but rather trigger the removal of a
>> device from device_del() via object_unparen
On Wed, Sep 26, 2018 at 11:42:13AM +0200, David Hildenbrand wrote:
> The unplug and unplug_request handlers are special: They are not
> executed when unrealizing a device, but rather trigger the removal of a
> device from device_del() via object_unparent() - to effectively
> unrealize a device.
>
>> Inside object_unparent(), the call flow of unrealize steps is defined.
>> By moving the "real unplug" part into "do_unplug" and therefor
>> essentially calling it when unrealizing, we could generalize this for
>> all unplug handlers.
>> I think, order of realization and therefore the order of ho
On Tue, 2 Oct 2018 11:49:09 +0200
David Hildenbrand wrote:
> On 01/10/2018 15:24, Igor Mammedov wrote:
> > On Fri, 28 Sep 2018 14:21:33 +0200
> > David Hildenbrand wrote:
> >
> >> On 27/09/2018 15:01, Igor Mammedov wrote:
> >>> On Wed, 26 Sep 2018 11:42:13 +0200
> >>> David Hildenbrand wro
On 01/10/2018 15:24, Igor Mammedov wrote:
> On Fri, 28 Sep 2018 14:21:33 +0200
> David Hildenbrand wrote:
>
>> On 27/09/2018 15:01, Igor Mammedov wrote:
>>> On Wed, 26 Sep 2018 11:42:13 +0200
>>> David Hildenbrand wrote:
>>>
The unplug and unplug_request handlers are special: They are no
On Fri, 28 Sep 2018 14:21:33 +0200
David Hildenbrand wrote:
> On 27/09/2018 15:01, Igor Mammedov wrote:
> > On Wed, 26 Sep 2018 11:42:13 +0200
> > David Hildenbrand wrote:
> >
> >> The unplug and unplug_request handlers are special: They are not
> >> executed when unrealizing a device, but ra
On 27/09/2018 15:01, Igor Mammedov wrote:
> On Wed, 26 Sep 2018 11:42:13 +0200
> David Hildenbrand wrote:
>
>> The unplug and unplug_request handlers are special: They are not
>> executed when unrealizing a device, but rather trigger the removal of a
>> device from device_del() via object_unparen
On Wed, 26 Sep 2018 11:42:13 +0200
David Hildenbrand wrote:
> The unplug and unplug_request handlers are special: They are not
> executed when unrealizing a device, but rather trigger the removal of a
> device from device_del() via object_unparent() - to effectively
> unrealize a device.
>
> If
The unplug and unplug_request handlers are special: They are not
executed when unrealizing a device, but rather trigger the removal of a
device from device_del() via object_unparent() - to effectively
unrealize a device.
If such a device has a child bus and another device attached to
that bus (e.g
20 matches
Mail list logo
