On 11/15/22 16:41, Emanuele Giuseppe Esposito wrote:
To sum up on what was discussed in this serie, I don't really see any
strong objection against these patches, so I will soon send v3 which is
pretty much the same except for patch 1, which will be removed.
I think these patches are useful and
To sum up on what was discussed in this serie, I don't really see any
strong objection against these patches, so I will soon send v3 which is
pretty much the same except for patch 1, which will be removed.
I think these patches are useful and will be even more meaningful to the
reviewer when in th
On Wed, Nov 9, 2022 at 1:24 PM Emanuele Giuseppe Esposito
wrote:
> > > What I do know is that it's extremely confusing to understand if a
> > > function that is *not* marked as coroutine_fn is actually being called
> > > also from coroutines or not.
Agreed. This is a huge point in favor of pushin
On Wed, Nov 9, 2022 at 12:24 PM Emanuele Giuseppe Esposito
wrote:
> CCing also Alberto and Paolo
>
> So basically I think what we need is something that scans the whole
> block layer code and puts the right coroutine_fn annotations (or
> assertions, if you want) in the right places.
>
> The rule s
Am 08/11/2022 um 17:19 schrieb Vladimir Sementsov-Ogievskiy:
> [add Stefan]
>
>
> On 11/8/22 18:09, Emanuele Giuseppe Esposito wrote:
>>
>>
>> Am 08/11/2022 um 15:48 schrieb Vladimir Sementsov-Ogievskiy:
>>> On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
These functions end up callin
On 11/8/22 19:19, Vladimir Sementsov-Ogievskiy wrote:
This is a lot better than our "coroutine_fn" sign, which actually do no check (and can't
do). Don't you plan to swap a "coroutine_fn" noop marker with more meaningful
IN_COROUTINE(); (or something like this, which just do assert(qemu_in_coro
[add Stefan]
On 11/8/22 18:09, Emanuele Giuseppe Esposito wrote:
Am 08/11/2022 um 15:48 schrieb Vladimir Sementsov-Ogievskiy:
On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
These functions end up calling bdrv_common_block_status_above(), a
generated_co_wrapper function.
generated_co_
Am 08/11/2022 um 15:48 schrieb Vladimir Sementsov-Ogievskiy:
> On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
>> These functions end up calling bdrv_common_block_status_above(), a
>> generated_co_wrapper function.
>
> generated_co_wrapper is not a coroutine_fn. Сonversely it's a function
>
On 11/4/22 12:56, Emanuele Giuseppe Esposito wrote:
These functions end up calling bdrv_common_block_status_above(), a
generated_co_wrapper function.
generated_co_wrapper is not a coroutine_fn. Сonversely it's a function that do
a class coroutine wrapping - start a coroutine and do POLL to wai
These functions end up calling bdrv_common_block_status_above(), a
generated_co_wrapper function.
In addition, they also happen to be always called in coroutine context,
meaning all callers are coroutine_fn.
This means that the g_c_w function will enter the qemu_in_coroutine()
case and eventually s
10 matches
Mail list logo
