On 02/01/2018 11:09 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:24 PM, Oleksandr Andrushchenko wrote:
On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Current xenbus frontend driver removal flow first disconn
On 02/01/2018 03:24 PM, Oleksandr Andrushchenko wrote:
>
>
> On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
>> On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Current xenbus frontend driver removal flow first disconnects
>>> the driver from xenbus a
On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Current xenbus frontend driver removal flow first disconnects
the driver from xenbus and then calls driver's remove callback.
This makes it impossible for the d
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Current xenbus frontend driver removal flow first disconnects
> the driver from xenbus and then calls driver's remove callback.
> This makes it impossible for the driver to listen to backend's
> state change
From: Oleksandr Andrushchenko
Current xenbus frontend driver removal flow first disconnects
the driver from xenbus and then calls driver's remove callback.
This makes it impossible for the driver to listen to backend's
state changes and synchronize the removal procedure.
Fix this by removing oth
From: Oleksandr Andrushchenko
Hi, all!
While working on DRM PV frontend driver I faced an issue with
driver removal, e.g. when driver's .remove callback is called
the driver is already disconnected form the xenbus and it is not
possible to synchronize the process of removal with the backend.
Bac