|
From: | Paolo Bonzini |
Subject: | Re: [RFC PATCH 0/4] block layer: split block APIs in graph and I/O |
Date: | Thu, 16 Sep 2021 21:49:02 +0200 |
On 15/09/2021 16:43, Stefan Hajnoczi wrote:
> On Wed, Sep 15, 2021 at 02:11:41PM +0200, Paolo Bonzini wrote:
>> On 13/09/21 15:10, Stefan Hajnoczi wrote:
>>> On Wed, Sep 08, 2021 at 09:10:17AM -0400, Emanuele Giuseppe Esposito wrote:
>>>> Currently, block layer APIs like block-backend.h contain a mix of
>>>> functions that are either running in the main loop and under the
>>>> BQL, or are thread-safe functions and run in iothreads performing I/O.
>>>> The functions running under BQL also take care of modifying the
>>>> block graph, by using drain and/or aio_context_acquire/release.
>>>> This makes it very confusing to understand where each function
>>>> runs, and what assumptions it provided with regards to thread
>>>> safety.
>>>>
>>>> We call the functions running under BQL "graph API", and
>>>> distinguish them from the thread-safe "I/O API".
>>>
>>> Maybe "BQL" is clearer than "graph" because not all functions classified
>>> as "graph" need to traverse/modify the graph.
>>
>> Bikeshedding, I like it! :)
>>
>> ... on the other hand, qemu-storage-daemon does not have a BQL (see patch
>> 1); "graph API" functions run from the main (monitor) thread.
>>
>> The characteristic of the "graph API" is that they affect global state, so
>> another possibility could be "global state API". But is there any global
>> state apart from the BlockDriverState graph and the associated
>> BlockBackends?
>
> I would be happy with that name too.
>
Sounds good to me too, thanks.
One more minor cosmetic thing: should I name the header
block-backend-global-state.h or using block-backend-gs.h is
straightforward enough?
Thank you,
Emanuele
[Prev in Thread] | Current Thread | [Next in Thread] |