On 09.06.22 17:27, Alberto Faria wrote:
For consistency with other I/O functions, and in preparation to
implement them using generated_co_wrapper.
Callers were updated using this Coccinelle script:
@@ expression child, offset, buf, bytes; @@
- bdrv_pread(child, offset, buf, bytes)
On 09.06.22 17:27, Alberto Faria wrote:
For consistency with other I/O functions, and in preparation to
implement bdrv_{pread,pwrite}() using generated_co_wrapper.
unsigned int fits in int64_t, so all callers remain correct.
bdrv_check_request32() is called further down the stack and causes -EI
On 09.06.22 17:27, Alberto Faria wrote:
They currently return the value of their headerlen/buflen parameter on
success. Returning 0 instead makes it clear that short reads/writes are
not possible.
Signed-off-by: Alberto Faria
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/cr
On 09.06.22 17:27, Alberto Faria wrote:
Swap 'buf' and 'bytes' around for consistency with
bdrv_co_{pread,pwrite}(), and in preparation to implement these
functions using generated_co_wrapper.
Callers were updated using this Coccinelle script:
@@ expression child, offset, buf, bytes, flags
On 09.06.22 17:27, Alberto Faria wrote:
They currently return the value of their 'bytes' parameter on success.
Make them return 0 instead, for consistency with other I/O functions and
in preparation to implement them using generated_co_wrapper. This also
makes it clear that short reads/writes ar
On 09.06.22 17:27, Alberto Faria wrote:
It does not mutate the buffer.
Signed-off-by: Alberto Faria
Reviewed-by: Paolo Bonzini
Reviewed-by: Stefan Hajnoczi
---
include/block/block_int-io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Hanna Reitz
On 09.06.22 17:27, Alberto Faria wrote:
bdrv_{pread,pwrite}() now return -EIO instead of -EINVAL when 'bytes' is
negative, making them consistent with bdrv_{preadv,pwritev}() and
bdrv_co_{pread,pwrite,preadv,pwritev}().
bdrv_pwrite_zeroes() now also calls trace_bdrv_co_pwrite_zeroes() and
clears
On 09.06.22 17:27, Alberto Faria wrote:
Also convert bdrv_pwrite_sync() to being implemented using
generated_co_wrapper.
Signed-off-by: Alberto Faria
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/io.c | 9 +
include/block/block-io.h | 8 ++--
2 f
On 09.06.22 17:27, Alberto Faria wrote:
Convert uses of bdrv_pwrite_sync() into bdrv_co_pwrite_sync() when the
callers are already coroutine_fn.
Signed-off-by: Alberto Faria
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Stefan Hajnoczi
---
block/parallels.c | 2 +-
block/qcow
On 09.06.22 17:27, Alberto Faria wrote:
Use bdrv_pwrite_sync() instead of calling bdrv_pwrite() and bdrv_flush()
separately.
Signed-off-by: Alberto Faria
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
---
block/qcow2.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
On 09.06.22 17:27, Alberto Faria wrote:
Start by making the interfaces of analogous non-coroutine and coroutine
functions consistent with each other, then implement the non-coroutine
ones using generated_co_wrapper.
For the bdrv_pwrite_sync() case, also add the missing
bdrv_co_pwrite_sync() func
On 17.05.22 13:35, Alberto Faria wrote:
They currently return the value of their 'bytes' parameter on success.
Make them return 0 instead, for consistency with other I/O functions and
in preparation to implement them using generated_co_wrapper. This also
makes it clear that short reads/writes ar
On 17.05.22 13:35, Alberto Faria wrote:
For consistency with other I/O functions, and in preparation to
implement it using generated_co_wrapper.
Callers were updated using this Coccinelle script:
@@ expression blk, offset, buf, bytes; @@
- blk_pread(blk, offset, buf, bytes)
+ blk
Hi
On Thu, Jun 23, 2022 at 5:43 PM Markus Armbruster wrote:
>
> marcandre.lur...@redhat.com writes:
>
> > From: Marc-André Lureau
> >
> > The generated visitor code includes abort() & assert(), we shouldn't
> > rely on the global "-i" headers to include the necessary system headers.
>
> Suggest
On 7/1/22 20:02, John Snow wrote:
On Wed, Jun 29, 2022 at 7:18 PM Richard Henderson
wrote:
On 6/29/22 13:45, Vladimir Sementsov-Ogievskiy wrote:
The following changes since commit ad4c7f529a279685da84297773b4ec8080153c2d:
Merge tag 'pull-semi-20220628' of https://gitlab.com/rth7680/qemu
On 17.05.22 13:37, Alberto Faria wrote:
Swap 'buf' and 'bytes' around for consistency with
blk_co_{pread,pwrite}(), and in preparation to implement these functions
using generated_co_wrapper.
Callers were updated using this Coccinelle script:
@@ expression blk, offset, buf, bytes, flags; @
On 17.05.22 13:37, Alberto Faria wrote:
For consistency with other I/O functions, and in preparation to
implement them using generated_co_wrapper.
Signed-off-by: Alberto Faria
---
block/block-backend.c | 6 +++---
include/sysemu/block-backend-io.h | 6 +++---
2 files changed, 6
On 17.05.22 13:38, Alberto Faria wrote:
It does not mutate the buffer.
Signed-off-by: Alberto Faria
---
include/sysemu/block-backend-io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Hanna Reitz
On 02/07/2022 08:33, Alberto Faria wrote:
Alberto, hello. I was testing this patch as follows:
./static-analyzer.py build target/ppc/mmu-hash64.c
@@ -627,9 +744,31 @@ def is_coroutine_fn(node: Cursor) -> bool:
else:
break
-return node.kind == CursorKind.FUNCTION_
On 17.05.22 13:38, Alberto Faria wrote:
We need to add include/sysemu/block-backend-io.h to the inputs of the
block-gen.c target defined in block/meson.build.
Signed-off-by: Alberto Faria
---
block/block-backend.c | 23 ---
block/coroutines.h|
On 01.07.22 18:15, John Snow wrote:
On Fri, Jul 1, 2022 at 4:05 AM Hanna Reitz wrote:
On 16.06.22 16:26, John Snow wrote:
In certain container environments we may not have FUSE at all, so skip
the test in this circumstance too.
Signed-off-by: John Snow
---
tests/qemu-iotests/108 | 5 +
On Mon, Jul 4, 2022 at 2:52 PM Hanna Reitz wrote:
> There are a couple of places where you decided to replace “*len”
> variables that used to store the return value by a plain “ret”. That
> seems good to me, given how these functions no longer return length
> values, but you haven’t done so consis
On Sat, Jul 02, 2022 at 12:33:23PM +0100, Alberto Faria wrote:
> This series introduces a static analyzer for QEMU. It consists of a
> single static-analyzer.py script that relies on libclang's Python
> bindings, and provides a common framework on which arbitrary static
> analysis checks can be dev
Hi Víctor,
On Mon, Jul 4, 2022 at 3:18 PM Víctor Colombo
wrote:
> And I receive an exception on the line above saying that node is of type
> NoneType. Seems that `node = node.referenced` is setting `node` to None
> in this case.
>
> I was unable to understand the root cause of it. Is this an inco
On 04/07/2022 13:57, Alberto Faria wrote:
Hi Víctor,
On Mon, Jul 4, 2022 at 3:18 PM Víctor Colombo
wrote:
And I receive an exception on the line above saying that node is of type
NoneType. Seems that `node = node.referenced` is setting `node` to None
in this case.
I was unable to understand t
On Mon, Jul 4, 2022 at 6:46 PM Víctor Colombo
wrote:
> Yes, this line is present at the beginning of the output
> Is this caused by problems with the code being analyzed or is it because
> libclang is getting confused with something that is outside of our
> control?
I think I found the problem: t
On 04/07/2022 15:04, Alberto Faria wrote:
On Mon, Jul 4, 2022 at 6:46 PM Víctor Colombo
wrote:
Yes, this line is present at the beginning of the output
Is this caused by problems with the code being analyzed or is it because
libclang is getting confused with something that is outside of our
con
On Mon, Jul 4, 2022 at 5:28 PM Daniel P. Berrangé wrote:
> Have you done any measurement see how much of the overhead is from
> the checks you implemented, vs how much is inherantly forced on us
> by libclang ? ie what does it look like if you just load the libclang
> framework and run it actross
On 6/27/22 20:52, Iris Chen wrote:
Signed-off-by: Iris Chen
---
hw/block/m25p80.c | 74 +++
1 file changed, 62 insertions(+), 12 deletions(-)
diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index 50b523e5b1..0156a70f5e 100644
--- a/hw/block/m25p
29 matches
Mail list logo
