The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with. Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step. This is the step for qapi/job.json.
Said commit explains the transforma
The has_FOO for pointer-valued FOO are redundant, except for arrays.
They are also a nuisance to work with. Recent commit "qapi: Start to
elide redundant has_FOO in generated C" provided the means to elide
them step by step. This is the step for qapi/block*.json.
Said commit explains the transfo
On Tue, Dec 13, 2022 at 8:09 PM Hanna Reitz wrote:
>
> On 13.12.22 16:56, Nir Soffer wrote:
> > On Mon, Dec 12, 2022 at 12:38 PM Hanna Reitz wrote:
> >> On 28.11.22 15:15, Nir Soffer wrote:
> >>> Extend the test finder to find tests with format (*.out.qcow2) or cache
> >>> specific (*.out.nocache
On 13.12.22 16:56, Nir Soffer wrote:
On Mon, Dec 12, 2022 at 12:38 PM Hanna Reitz wrote:
On 28.11.22 15:15, Nir Soffer wrote:
Extend the test finder to find tests with format (*.out.qcow2) or cache
specific (*.out.nocache) out file. This worked before only for the
numbered tests.
---
tests/
On Mon, Dec 12, 2022 at 12:38 PM Hanna Reitz wrote:
>
> On 28.11.22 15:15, Nir Soffer wrote:
> > Extend the test finder to find tests with format (*.out.qcow2) or cache
> > specific (*.out.nocache) out file. This worked before only for the
> > numbered tests.
> > ---
> > tests/qemu-iotests/findt
On 12/13/22 01:30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What are you talking about? Of course it does.
The host CPU certainly does, but the virtio devi
On Tue, 13 Dec 2022 00:05:14 +0100
Philippe Mathieu-Daudé wrote:
> Since the device endianness doesn't change at runtime,
> use the cached value instead of evaluating it on each call.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/virtio/virtio-access.h | 44 +++--
From: Emanuele Giuseppe Esposito
BlockDriver->bdrv_getlength is categorized as IO callback, and it
currently doesn't run in a coroutine. We should let it take a graph
rdlock since the callback traverses the block nodes graph, which however
is only possible in a coroutine.
Therefore turn it into
From: Emanuele Giuseppe Esposito
bdrv_is_inserted() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
Therefore turn it into a co_wrapper to
From: Emanuele Giuseppe Esposito
bdrv_lock_medium() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
The only caller of this function is bl
From: Emanuele Giuseppe Esposito
Since these functions always run in coroutine context, adjust
their name to include "_co_", just like all other BlockDriver callbacks.
No functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
include/block/block_i
From: Emanuele Giuseppe Esposito
bdrv_get_info() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
Therefore turn it into a co_wrapper to mo
From: Emanuele Giuseppe Esposito
bdrv_get_allocated_file_size() is categorized as an I/O function, and it
currently doesn't run in a coroutine. We should let it take a graph
rdlock since it traverses the block nodes graph, which however is only
possible in a coroutine.
Therefore turn it into a c
From: Emanuele Giuseppe Esposito
The name is not good, not the least because we are going to convert this
to a generated co_wrapper, which adds a _co infix after the first part
of the name.
No functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
From: Emanuele Giuseppe Esposito
BlockDriver->bdrv_io_plug is categorized as IO callback, and it
currently doesn't run in a coroutine. We should let it take a graph
rdlock since the callback traverses the block nodes graph, which however
is only possible in a coroutine.
The only caller of this f
From: Emanuele Giuseppe Esposito
In some places we are sure we are always running in a
coroutine, therefore it's useless to call the generated_co_wrapper,
instead call directly the _co_ function.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
block/block-backend.c | 6
From: Emanuele Giuseppe Esposito
BlockDriver->bdrv_io_unplug is categorized as IO callback, and it
currently doesn't run in a coroutine. We should let it take a graph
rdlock since the callback traverses the block nodes graph, which however
is only possible in a coroutine.
The only caller of this
From: Emanuele Giuseppe Esposito
bdrv_debug_event() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
Therefore turn it into a co_wrapper_mi
This series converts some IO_CODE() functions to coroutine_fn because
they access the graph and will need to hold the graph lock in the
future. IO_CODE() functions can be called from iothreads, so taking the
graph lock requires the function to run in coroutine context.
Pretty much all of the chang
From: Emanuele Giuseppe Esposito
The only difference is that blk_ checks if the block is available,
but this check is already performed above in blk_check_byte_request().
This is in preparation for the graph rdlock, which will be taken
by both the callers of blk_check_byte_request() and blk_getl
From: Emanuele Giuseppe Esposito
bdrv_eject() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
The only caller of this function is blk_ejec
From: Emanuele Giuseppe Esposito
Just omit the various 'return' when the return type is void.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
scripts/block-coroutine-wrapper.py | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/sc
On 13/12/2022 09.32, Philippe Mathieu-Daudé wrote:
On 13/12/22 09:03, Thomas Huth wrote:
On 13/12/2022 08.30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What
On 13/12/22 09:03, Thomas Huth wrote:
On 13/12/2022 08.30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What are you talking about? Of course it does.
The hos
On 13/12/22 08:30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What are you talking about? Of course it does.
The host CPU certainly does, but the virtio devi
On Nov 25 10:48, Joel Granados wrote:
> The motivation and description are contained in the last patch in this set.
> Will copy paste it here for convenience:
>
> In order to evaluate write amplification factor (WAF) within the storage
> stack it is important to know the number of bytes wr
On 13/12/2022 08.30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What are you talking about? Of course it does.
The host CPU certainly does, but the virtio de
27 matches
Mail list logo
