When erasing the chip, use the typical time specified in the CFI table
rather than arbitrarily selecting 5 seconds.
Since the currently unconfigurable value set in the table is 12, this
means a chip erase takes 4096 ms so this isn't a big change in behavior.
Signed-off-by: Stephen Checkoway
---
After a flash device enters CFI mode from autoselect mode, the reset
command returns the device to autoselect mode. An additional reset
command is necessary to return to read array mode.
Signed-off-by: Stephen Checkoway
---
hw/block/pflash_cfi02.c | 21 +
During a sector erase (but not a chip erase), the embeded erase program
can be suspended. Once suspended, the sectors not selected for erasure
may be read and programmed. Autoselect mode is allowed during erase
suspend mode. Presumably, CFI queries are similarly allowed so this
commit allows them
It's common for multiple narrow flash chips to be hooked up in parallel
to support wider buses. For example, four 8-bit wide flash chips (x8)
may be combined in parallel to produce a 32-bit wide device. Similarly,
two 16-bit wide chips (x16) may be combined.
This commit introduces `device-width`
Some flash chips support sectors of different sizes. For example, the
AMD AM29LV160DT has 31 64 kB sectors, one 32 kB sector, two 8 kB
sectors, and a 16 kB sector, in that order. The AM29LV160DB has those in
the reverse order.
The `num-blocks` and `sector-length` properties work exactly as they
After two unlock cycles and a sector erase command, the AMD flash chips
start a 50 us erase time out. Any additional sector erase commands add a
sector to be erased and restart the 50 us timeout. During the timeout,
status bit DQ3 is cleared. After the time out, DQ3 is asserted during
erasure.
When the flash device is performing a chip erase, all commands are
ignored. When it is performing a sector erase, only the erase suspend
command is valid, which is currently not supported.
In particular, the reset command should not cause the device to reset to
read array mode while programming
Simplify and refactor for upcoming commits. In particular, pull out all
of the code to modify the status into simple helper functions. Status
handling becomes more complex once multiple chips are interleaved to
produce a single device.
No change in functionality is intended with this commit.
Test the AMD command set for parallel flash chips. This test uses an
ARM musicpal board with a pflash drive to test the following list of
currently-supported commands.
- Autoselect
- CFI
- Sector erase
- Chip erase
- Program
- Unlock bypass
- Reset
Signed-off-by: Stephen Checkoway
---
Most AMD commands only examine 11 bits of the address. This masks the
addresses used in the comparison to 11 bits. The exceptions are word or
sector addresses which use offset directly rather than the shifted
offset, boff.
Signed-off-by: Stephen Checkoway
---
hw/block/pflash_cfi02.c | 8
The goal of this patch series implement the following AMD command-set parallel
flash functionality:
- flash interleaving;
- nonuniform sector sizes;
- erase suspend/resume commands; and
- multi-sector erase.
During refactoring and implementation, I discovered several bugs that are
fixed here as
Patchew URL:
https://patchew.org/QEMU/cover.1554755001.git.stephen.checko...@oberlin.edu/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: cover.1554755001.git.stephen.checko...@oberlin.edu
Subject: [Qemu-devel] [PATCH 00/10]
During a sector erase (but not a chip erase), the embeded erase program
can be suspended. Once suspended, the sectors not selected for erasure
may be read and programmed. Autoselect mode is allowed during erase
suspend mode. Presumably, CFI queries are similarly allowed so this
commit allows them
From: Stephen Checkoway
Simplify and refactor for upcoming commits. In particular, pull out all
of the code to modify the status into simple helper functions. Status
handling becomes more complex once multiple chips are interleaved to
produce a single device.
No change in functionality is
After two unlock cycles and a sector erase command, the AMD flash chips
start a 50 us erase time out. Any additional sector erase commands add a
sector to be erased and restart the 50 us timeout. During the timeout,
status bit DQ3 is cleared. After the time out, DQ3 is asserted during
erasure.
When erasing the chip, use the typical time specified in the CFI table
rather than arbitrarily selecting 5 seconds.
Since the currently unconfigurable value set in the table is 12, this
means a chip erase takes 4096 ms so this isn't a big change in behavior.
Signed-off-by: Stephen Checkoway
---
It's common for multiple narrow flash chips to be hooked up in parallel
to support wider buses. For example, four 8-bit wide flash chips (x8)
may be combined in parallel to produce a 32-bit wide device. Similarly,
two 16-bit wide chips (x16) may be combined.
This commit introduces `device-width`
Some flash chips support sectors of different sizes. For example, the
AMD AM29LV160DT has 31 64 kB sectors, one 32 kB sector, two 8 kB
sectors, and a 16 kB sector, in that order. The AM29LV160DB has those in
the reverse order.
The `num-blocks` and `sector-length` properties work exactly as they
From: Stephen Checkoway
Most AMD commands only examine 11 bits of the address. This masks the
addresses used in the comparison to 11 bits. The exceptions are word or
sector addresses which use offset directly rather than the shifted
offset, boff.
Signed-off-by: Stephen Checkoway
---
After a flash device enters CFI mode from autoselect mode, the reset
command returns the device to autoselect mode. An additional reset
command is necessary to return to read array mode.
Signed-off-by: Stephen Checkoway
---
hw/block/pflash_cfi02.c | 21 +
When the flash device is performing a chip erase, all commands are
ignored. When it is performing a sector erase, only the erase suspend
command is valid, which is currently not supported.
In particular, the reset command should not cause the device to reset to
read array mode while programming
From: Stephen Checkoway
Test the AMD command set for parallel flash chips. This test uses an
ARM musicpal board with a pflash drive to test the following list of
currently-supported commands.
- Autoselect
- CFI
- Sector erase
- Chip erase
- Program
- Unlock bypass
- Reset
Signed-off-by: Stephen
The goal of this patch series implement the following AMD command-set parallel
flash functionality:
- flash interleaving;
- nonuniform sector sizes;
- erase suspend/resume commands; and
- multi-sector erase.
During refactoring and implementation, I discovered several bugs that are
fixed here as
On 4/8/19 3:36 AM, Markus Armbruster wrote:
> Callbacks ssh_co_readv(), ssh_co_writev(), ssh_co_flush() report
> errors to the user with error_printf(). They shouldn't, it's their
> caller's job. Replace by a suitable trace point.
>
> Perhaps we should convert this part of the block driver
On Mon, 8 Apr 2019 at 17:35, Kevin Wolf wrote:
>
> The following changes since commit f55a585d1037e5de6088f25e75443c2776786e29:
>
> Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
> (2019-04-07 14:54:55 +0100)
>
> are available in the Git repository at:
>
>
On 28.02.19 10:26, Andrey Shinkevich wrote:
> When a bitmap is removed, we can clean some space on the disk. The size
> of a cluster may be larger, so is the size of the bitmap that includes
> many clusters. Some bitmaps can be as large as tens of megabytes.
> The flag QCOW2_DISCARD_ALWAYS allows
Don't increment remaining_bytes until we know that we will actually be
including the current block status extent in the reply; otherwise, the
value traced will include a bytes value that is oversized by the
length of the next block status extent which did not get sent because
it instead ended the
We've recently added traces for clients to flag server non-compliance;
let's do the same for servers to flag client non-compliance. According
to the spec, if the client requests NBD_INFO_BLOCK_SIZE, it is
promising to send all requests aligned to those boundaries. Of
course, if the client does
In commit 0c1d50bd, I added a couple of TODO comments about whether we
consult bl.request_alignment when responding to NBD_OPT_INFO. At the
time, qemu as server was hard-coding an advertised alignment of 512 to
clients that promised to obey constraints, and there was no function
for getting at a
Add a missing space to the error message used when giving up on a
server that insists on an alignment which renders the last few bytes
of the export unreadable.
Fixes: 3add3ab78
Signed-off-by: Eric Blake
Message-Id: <20190404145226.32649-1-ebl...@redhat.com>
Reviewed-by: Kevin Wolf
---
On 4/8/19 3:36 AM, Markus Armbruster wrote:
> error_exit() uses low-level error_printf() to report errors.
> Modernize it to use error_vreport().
>
> Cc: Kevin Wolf
> Cc: Max Reitz
> Cc: qemu-block@nongnu.org
> Signed-off-by: Markus Armbruster
> ---
> qemu-img.c | 6 ++
> 1 file changed,
On 08.04.19 19:22, Richard W.M. Jones wrote:
> I don't know much about this patch which looks like internal qemu
> rearrangements so I guess fine. However I do have a few things to say
> about the ssh driver ...
>
> As you know I wrote this a few years ago, and it uses libssh2.
> libssh2 has not
This patch is used in the 'block/stream: introduce a bottom node'
that is following. Instead of the base node, the caller may pass
the node that has the base as its backing image to the function
bdrv_is_allocated_above() with a new parameter include_base = true
and get rid of the dependency on the
The bottom node is the intermediate block device that has the base as its
backing image. It is used instead of the base node while a block stream
job is running to avoid dependency on the base that may change due to the
parallel jobs. The change may take place due to a filter node as well that
is
This series introduces a bottom intermediate node that eliminates the
dependency on the base that may change while stream job is running.
It happens when stream/commit parallel jobs are running on the same
backing chain. The base node of the stream job may be a top node of
the parallel commit job
From: Vladimir Sementsov-Ogievskiy
The goto is unnecessary in the stream_run() since the common exit
code was removed in the commit eb23654dbe43b549ea2a9ebff9d8e:
"jobs: utilize job_exit shim".
Signed-off-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Andrey Shinkevich
Reviewed-by: Alberto
On 08/04/2019 18:39, Alberto Garcia wrote:
> On Fri 05 Apr 2019 06:56:19 PM CEST, Andrey Shinkevich wrote:
>> @@ -232,8 +232,13 @@ void stream_start(const char *job_id, BlockDriverState
>> *bs,
>> StreamBlockJob *s;
>> BlockDriverState *iter;
>> bool bs_read_only;
>> +
On Mon, Apr 08, 2019 at 08:07:00PM +0200, Markus Armbruster wrote:
> "Richard W.M. Jones" writes:
>
> > I don't know much about this patch which looks like internal qemu
> > rearrangements so I guess fine. However I do have a few things to say
> > about the ssh driver ...
> >
> > As you know I
"Richard W.M. Jones" writes:
> I don't know much about this patch which looks like internal qemu
> rearrangements so I guess fine. However I do have a few things to say
> about the ssh driver ...
>
> As you know I wrote this a few years ago, and it uses libssh2.
> libssh2 has not evolved as
I don't know much about this patch which looks like internal qemu
rearrangements so I guess fine. However I do have a few things to say
about the ssh driver ...
As you know I wrote this a few years ago, and it uses libssh2.
libssh2 has not evolved as quickly as we'd like and it may be better
to
When bdrv_temp_snapshot_options() is called for snapshot=on, the
'discard' option in the options QDict hasn't been parsed and merged into
the flags yet. So copy the dict entry to make sure that the temporary
overlay enables discard when it was requested for the drive.
Signed-off-by: Kevin Wolf
From: Markus Armbruster
drive_new() returns null without setting an error when it provided
help. add_init_drive() assumes null means failure, and crashes trying
to report a null error.
Fixes: c4f26c9f37ce511e5fe629c21c180dc6eb7c5a25
Cc: qemu-sta...@nongnu.org
Signed-off-by: Markus Armbruster
The following changes since commit f55a585d1037e5de6088f25e75443c2776786e29:
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
(2019-04-07 14:54:55 +0100)
are available in the Git repository at:
git://repo.or.cz/qemu/kevin.git tags/for-upstream
for you to fetch
On Mon, Apr 08, 2019 at 16:35:39 +0200, Kevin Wolf wrote:
> This series adds optional feature lists to struct definitions in the
> QAPI schema and makes use of them to advertise the new behaviour of
> auto-read-only=on in file-posix.
>
> Kevin Wolf (4):
> qapi: Support features for structs
>
drv_co_block_status digs bs->file for additional, more accurate search
for hole inside region, reported as DATA by bs since 5daa74a6ebc.
This accuracy is not free: assume we have qcow2 disk. Actually, qcow2
knows, where are holes and where is data. But every block_status
request calls lseek
Hi!
It's a continuation for
"[PATCH] qcow2: avoid lseek on block_status if possible"
https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06598.html
performance results for block-status on tmpfs [tests originally by Kevin,
now they are in 01]:
./tests/perf/block/qcow2/convert-blockstatus
Block layer may recursively check block_status in file child of qcow2,
if qcow2 driver returned DATA. There are several test cases to check
influence of lseek on block_status performance. To see real difference
run on tmpfs.
Tests originally created by Kevin, I just refactored and put them
On 4/8/19 5:30 PM, Markus Armbruster wrote:
> drive_new() returns null without setting an error when it provided
> help. add_init_drive() assumes null means failure, and crashes trying
> to report a null error.
>
> Fixes: c4f26c9f37ce511e5fe629c21c180dc6eb7c5a25
> Cc: qemu-sta...@nongnu.org
>
Am 08.04.2019 um 17:30 hat Markus Armbruster geschrieben:
> drive_new() returns null without setting an error when it provided
> help. add_init_drive() assumes null means failure, and crashes trying
> to report a null error.
>
> Fixes: c4f26c9f37ce511e5fe629c21c180dc6eb7c5a25
> Cc:
On 08/04/2019 18:39, Alberto Garcia wrote:
> On Fri 05 Apr 2019 06:56:19 PM CEST, Andrey Shinkevich wrote:
>> @@ -232,8 +232,13 @@ void stream_start(const char *job_id, BlockDriverState
>> *bs,
>> StreamBlockJob *s;
>> BlockDriverState *iter;
>> bool bs_read_only;
>> +
On Fri 05 Apr 2019 06:56:19 PM CEST, Andrey Shinkevich wrote:
> @@ -232,8 +232,13 @@ void stream_start(const char *job_id, BlockDriverState
> *bs,
> StreamBlockJob *s;
> BlockDriverState *iter;
> bool bs_read_only;
> +BlockDriverState *bottom = NULL;
> +int basic_flags =
* Markus Armbruster (arm...@redhat.com) wrote:
> drive_new() returns null without setting an error when it provided
> help. add_init_drive() assumes null means failure, and crashes trying
> to report a null error.
>
> Fixes: c4f26c9f37ce511e5fe629c21c180dc6eb7c5a25
> Cc: qemu-sta...@nongnu.org
>
drive_new() returns null without setting an error when it provided
help. add_init_drive() assumes null means failure, and crashes trying
to report a null error.
Fixes: c4f26c9f37ce511e5fe629c21c180dc6eb7c5a25
Cc: qemu-sta...@nongnu.org
Signed-off-by: Markus Armbruster
---
v2: Make
On 08/04/2019 18:22, Alberto Garcia wrote:
> On Mon 08 Apr 2019 05:16:22 PM CEST, Andrey Shinkevich wrote:
>> On 08/04/2019 18:03, Alberto Garcia wrote:
>>> On Fri 05 Apr 2019 06:56:17 PM CEST, Andrey Shinkevich wrote:
+int bdrv_is_allocated_above(BlockDriverState *top,
+
On Mon 08 Apr 2019 05:16:22 PM CEST, Andrey Shinkevich wrote:
> On 08/04/2019 18:03, Alberto Garcia wrote:
>> On Fri 05 Apr 2019 06:56:17 PM CEST, Andrey Shinkevich wrote:
>>> +int bdrv_is_allocated_above(BlockDriverState *top,
>>> +BlockDriverState *base,
>>> +
To better support use of IOThread-s it will be necessary to be able to set
the AioContext for each XenEventChannel and hence it is necessary to open a
separate handle to libxenevtchan for each channel.
This patch stops using NotifierList for event channel callbacks, replacing
that construct by a
On 08/04/2019 18:03, Alberto Garcia wrote:
> On Fri 05 Apr 2019 06:56:17 PM CEST, Andrey Shinkevich wrote:
>> +int bdrv_is_allocated_above(BlockDriverState *top,
>> +BlockDriverState *base,
>> +int64_t offset, int64_t bytes, int64_t *pnum)
Currently xen-block uses an IOThread to handle AIO but the event channels
are dealt with on QEMU's main thread. This series allows them to be
dealt with in the same context.
Paul Durrant (3):
xen-bus: use a separate fd for each event channel
xen-bus: allow AioContext to be specified for each
This patch adds an AioContext parameter to xen_device_bind_event_channel()
and then uses aio_set_fd_handler() to set the callback rather than
qemu_set_fd_handler().
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Stefan Hajnoczi
Cc: Kevin Wolf
Cc: Max Reitz
---
This patch introduces a poll callback for event channel fd-s and uses
this to invoke the channel callback function.
To properly support polling, it is necessary for the event channel callback
function to return a boolean saying whether it has done any useful work or
not. Thus
08.04.2019 18:03, Alberto Garcia wrote:
> On Fri 05 Apr 2019 06:56:17 PM CEST, Andrey Shinkevich wrote:
>> +int bdrv_is_allocated_above(BlockDriverState *top,
>> +BlockDriverState *base,
>> +int64_t offset, int64_t bytes, int64_t *pnum)
>> +{
On 08.04.19 16:57, Vladimir Sementsov-Ogievskiy wrote:
> 23.01.2019 18:48, Max Reitz wrote:
>> Hi,
>>
>> When running 169 in parallel (e.g. like so:
>>
>> $ while TEST_DIR=/tmp/t0 ./check -T -qcow2 169; do; done
>> $ while TEST_DIR=/tmp/t1 ./check -T -qcow2 169; do; done
>> $ while
On Fri 05 Apr 2019 06:56:17 PM CEST, Andrey Shinkevich wrote:
> +int bdrv_is_allocated_above(BlockDriverState *top,
> +BlockDriverState *base,
> +int64_t offset, int64_t bytes, int64_t *pnum)
> +{
> +return bdrv_do_is_allocated_above(top,
23.01.2019 18:48, Max Reitz wrote:
> Hi,
>
> When running 169 in parallel (e.g. like so:
>
> $ while TEST_DIR=/tmp/t0 ./check -T -qcow2 169; do; done
> $ while TEST_DIR=/tmp/t1 ./check -T -qcow2 169; do; done
> $ while TEST_DIR=/tmp/t2 ./check -T -qcow2 169; do; done
> $ while TEST_DIR=/tmp/t3
In commit 23dece19da4 ('file-posix: Make auto-read-only dynamic') ,
auto-read-only=on changed its behaviour in file-posix for the 4.0
release. This change cannot be detected through the usual mechanisms
like schema introspection. Add a new feature flag to the schema to
allow libvirt to detect the
Signed-off-by: Kevin Wolf
---
tests/qapi-schema/qapi-schema-test.json | 27 +
tests/qapi-schema/qapi-schema-test.out | 26
tests/qapi-schema/test-qapi.py | 4
3 files changed, 57 insertions(+)
diff --git
Sometimes, the behaviour of QEMU changes compatibly, but without a
change in the QMP syntax (usually by allowing values or operations that
previously resulted in an error). QMP clients may still need to know
whether the extension is available.
This allows to add a list of features to struct
Signed-off-by: Kevin Wolf
---
tests/qapi-schema/features-bad-type.json | 3 +++
tests/qapi-schema/features-missing-name.json | 3 +++
tests/qapi-schema/features-name-bad-type.json | 3 +++
tests/qapi-schema/features-no-list.json | 3 +++
tests/qapi-schema/features-unknown-key.json
This series adds optional feature lists to struct definitions in the
QAPI schema and makes use of them to advertise the new behaviour of
auto-read-only=on in file-posix.
Kevin Wolf (4):
qapi: Support features for structs
tests/qapi-schema: Test for good feature lists in structs
On 4/8/19 7:14 AM, Vladimir Sementsov-Ogievskiy wrote:
> 05.04.2019 23:04, Eric Blake wrote:
>> On 4/5/19 9:39 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> 03.04.2019 6:05, Eric Blake wrote:
We've recently added traces for clients to flag server non-compliance;
let's do the same for
05.04.2019 19:56, Andrey Shinkevich wrote:
> The bottom node is the intermediate block device that has the base as its
> backing image. It is used instead of the base node while a block stream
> job is running to avoid dependency on the base that may change due to the
> parallel jobs. The change
Sorry, I am a newbie. I have never used this kind of thing before.
I will definitely pay attention next time.
-- Original --
From: "Kevin Wolf";
Date: Mon, Apr 8, 2019 06:39 PM
To: "ghorges";
Cc: "qemu-devel"; "qemu-block";
Subject: Re: [Qemu-devel]
---
linux-user/syscall.c | 66 ++--
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 208fd1813d..985095e4d5 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -8240,7 +8240,7 @@
03.04.2019 6:05, Eric Blake wrote:
> Previous commits have mentioned that our NBD server still sends
> unaligned fragments when an active layer with large advertised minimum
> block size is backed by another layer with a smaller block
> size. Expand the test to actually cover this scenario, by
05.04.2019 23:04, Eric Blake wrote:
> On 4/5/19 9:39 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 03.04.2019 6:05, Eric Blake wrote:
>>> We've recently added traces for clients to flag server non-compliance;
>>> let's do the same for servers to flag client non-compliance. According
>
> Thus,
On 08/04/2019 13:04, Kevin Wolf wrote:
> Am 08.04.2019 um 11:44 hat Andrey Shinkevich geschrieben:
>>
>>
>> On 06/04/2019 01:50, John Snow wrote:
>>>
>>>
>>> On 4/5/19 10:24 AM, Andrey Shinkevich wrote:
On a file system used by the customer, fallocate() returns an error
if the block is
On 4/8/19 10:36 AM, Markus Armbruster wrote:
> Command line help explicitly requested by the user should be printed
> to stdout, not stderr. We do elsewhere. Adjust -drive to match: use
> qemu_printf() instead of error_printf(). Plain printf() would be
> wrong because we need to print to the
Am 08.04.2019 um 10:40 hat ghorges geschrieben:
> ---
> linux-user/syscall.c | 66 ++--
> 1 file changed, 33 insertions(+), 33 deletions(-)
Thomas already gave you some hints what to improve. I'd just like to add
that you shouldn't send the email to the
Hi,
thanks for your patch! But please add a short patch description (beside
the subject), e.g. "Change the name of some variables so that the code
can be compiled with -Wshadow, too".
And you've got to put a "Signed-off-by" line at the end of the patch
description, too. See this URL for
Am 08.04.2019 um 12:04 hat Kevin Wolf geschrieben:
> Am 08.04.2019 um 11:44 hat Andrey Shinkevich geschrieben:
> >
> >
> > On 06/04/2019 01:50, John Snow wrote:
> > >
> > >
> > > On 4/5/19 10:24 AM, Andrey Shinkevich wrote:
> > >> On a file system used by the customer, fallocate() returns an
Am 08.04.2019 um 11:44 hat Andrey Shinkevich geschrieben:
>
>
> On 06/04/2019 01:50, John Snow wrote:
> >
> >
> > On 4/5/19 10:24 AM, Andrey Shinkevich wrote:
> >> On a file system used by the customer, fallocate() returns an error
> >> if the block is not properly aligned. So,
PINGING
I kindly remind you about this small patch for QEMU 4.1.
I am going to be away for vacation from April, 10th to May, 15th.
--
With the best regards,
Andrey Shinkevich
On 19/03/2019 01:18, John Snow wrote:
>
>
> On 2/28/19 4:26 AM, Andrey Shinkevich wrote:
>> When a bitmap is removed,
On 06/04/2019 01:50, John Snow wrote:
>
>
> On 4/5/19 10:24 AM, Andrey Shinkevich wrote:
>> On a file system used by the customer, fallocate() returns an error
>> if the block is not properly aligned. So, bdrv_co_pwrite_zeroes()
>> fails. We can handle that case the same way as it is done for
On 08/04/2019 12:00, Stefan Hajnoczi wrote:
> On Fri, Apr 05, 2019 at 05:24:04PM +0300, Andrey Shinkevich wrote:
>> On a file system used by the customer, fallocate() returns an error
>> if the block is not properly aligned. So, bdrv_co_pwrite_zeroes()
>> fails. We can handle that case the same
Patchew URL:
https://patchew.org/QEMU/20190408084056.26212-1-ghor...@xiyoulinux.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190408084056.26212-1-ghor...@xiyoulinux.org
Subject: [Qemu-devel] Wshadow in
On Fri, Apr 05, 2019 at 05:24:04PM +0300, Andrey Shinkevich wrote:
> On a file system used by the customer, fallocate() returns an error
> if the block is not properly aligned. So, bdrv_co_pwrite_zeroes()
> fails. We can handle that case the same way as it is done for the
> unsupported cases,
Command line help explicitly requested by the user should be printed
to stdout, not stderr. We do elsewhere. Adjust -drive to match: use
qemu_printf() instead of error_printf(). Plain printf() would be
wrong because we need to print to the current monitor for "drive_add
... format=help".
Cc:
error_exit() uses low-level error_printf() to report errors.
Modernize it to use error_vreport().
Cc: Kevin Wolf
Cc: Max Reitz
Cc: qemu-block@nongnu.org
Signed-off-by: Markus Armbruster
---
qemu-img.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/qemu-img.c
Callbacks ssh_co_readv(), ssh_co_writev(), ssh_co_flush() report
errors to the user with error_printf(). They shouldn't, it's their
caller's job. Replace by a suitable trace point.
Perhaps we should convert this part of the block driver interface to
Error, so block drivers can pass more detail
89 matches
Mail list logo
