On 08/02/2014 09:35 PM, Michael Tokarev wrote:
06.07.2014 12:43, Chen Gang wrote:
getchar() is a standard c library function which may return with failure
(e.g. -1), so like another platforms, also need check it under WIN32.
Applied to -trivial queue, with a slight modification:
Thanks
In dump_init(), when failure occurs, need notice about 'fd' and memory
mapping. So call dump_cleanup() for it (need let all initializations at
front).
Also simplify dump_cleanup(): remove redundant 'ret' and redundant 'fd'
checking.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
dump.c
On 08/03/2014 11:56 PM, Laszlo Ersek wrote:
comments below
Excuse me for replying late, firstly.
On 08/03/14 17:28, Chen Gang wrote:
In dump_init(), when failure occurs, need notice about 'fd' and memory
mapping. So call dump_cleanup() for it (need let all initializations at
front
for sending
patches.
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed
.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
On 08/05/2014 04:07 PM, Peter Maydell wrote:
n 5 August 2014 08:08, Michael Tokarev m...@tls.msk.ru wrote:
05.08.2014 08:41, Chen Gang wrote:
Every members have their own tastes, and one working flow may be not
suitable for all members. I can understand, and hope other members
understand
If this patch need still be improvement (e.g. need let dump_cleanup
function as a generic one, or other cases), please let me know, and I
shall send patch v2 for it.
Thanks.
On 08/04/2014 09:51 PM, Chen Gang wrote:
On 08/03/2014 11:56 PM, Laszlo Ersek wrote:
comments below
Excuse me
On 08/12/2014 11:43 PM, Laszlo Ersek wrote:
On 08/03/14 17:28, Chen Gang wrote:
In dump_init(), when failure occurs, need notice about 'fd' and memory
mapping. So call dump_cleanup() for it (need let all initializations at
front).
Also simplify dump_cleanup(): remove redundant 'ret
On 08/15/2014 04:49 AM, Luiz Capitulino wrote:
On Sun, 03 Aug 2014 23:28:56 +0800
Chen Gang gang.chen.5...@gmail.com wrote:
In dump_init(), when failure occurs, need notice about 'fd' and memory
mapping. So call dump_cleanup() for it (need let all initializations at
front).
Also
For valid 'fd' (in most cases), it is enough to only check whether it
is larger than STDERR_FILENO, so recommend to move if (fd 0) into
failure processing block.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git
Firstly, thank you very much for your reply, this is my first patch for
qemu. Next year (2014), as a volunteer, I will try to make a patch for
qemu in each month. :-)
On 12/29/2013 07:43 AM, Peter Maydell wrote:
On 28 December 2013 08:52, Chen Gang gang.chen.5...@gmail.com wrote:
For valid
... not support for this target, it can avoid to print
... accelerator does not exist.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vl.c b/vl.c
index 842e897..b4f98fa 100644
--- a/vl.c
+++ b/vl.c
@@ -2709,7 +2709,7
On 03/27/2014 03:55 PM, Marcel Apfelbaum wrote:
On Thu, 2014-03-27 at 09:16 +0800, Chen Gang wrote:
At present, each 'opt_name' of 'accel_list' is uniq with each other, so
'buf' can only match one 'opt_name'.
When drop into the matching code block, can 'break' outside related
'for' looping
On 03/27/2014 04:59 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
At present, each 'opt_name' of 'accel_list' is uniq with each other, so
'buf' can only match one 'opt_name'.
When drop into the matching code block, can 'break' outside related
'for' looping after
block).
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c | 36 +---
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/vl.c b/vl.c
index 9975e5a..9c733cb 100644
--- a/vl.c
+++ b/vl.c
@@ -1188,18 +1188,16 @@ DeviceState *get_boot_device(uint32_t
is the best to Qemu.
Thanks.
On 03/30/2014 10:34 PM, Chen Gang wrote:
in get_boot_device()
- remove 'res' to simplify code
in main():
- remove useless 'continue'.
- in main switch():
- remove or adjust all useless 'break'.
- remove useless '{' and '}'.
- use assignment
Hello Maintainers:
If it is necessary to send patch v2 by me, please let me know, I
will/should send.
Thanks.
On 03/27/2014 06:01 PM, Chen Gang wrote:
On 03/27/2014 04:59 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
At present, each 'opt_name' of 'accel_list
On 03/31/2014 08:38 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
Hello Maintainers:
If it is necessary to send patch v2 by me, please let me know, I
will/should send.
Not a maintainer, but if you send a v2 with an improved commit message,
I'll R-by it, which
On 03/31/2014 09:01 PM, Peter Maydell wrote:
On 31 March 2014 13:53, Chen Gang gang.chen.5...@gmail.com wrote:
On 03/31/2014 08:38 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
Hello Maintainers:
If it is necessary to send patch v2 by me, please let me know, I
On 03/31/2014 09:16 PM, Peter Maydell wrote:
On 31 March 2014 14:12, Chen Gang gang.chen.5...@gmail.com wrote:
Next, when I send trivial patches, I will/should cc to qemu-trivial. I
guess, most of my future patches will be trivial patches (and for me,
trivial != minor).
We describe
On 03/31/2014 09:33 PM, Peter Maydell wrote:
On 31 March 2014 14:26, Chen Gang gang.chen.5...@gmail.com wrote:
Next, when I send trivial patches, I will only send to qemu-trivial (not
send/cc to qemu-devel again), that will be more efficient. :-)
No, please always send to qemu-devel; just
On 03/31/2014 11:49 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
in get_boot_device()
- remove 'res' to simplify code
in main():
- remove useless 'continue'.
- in main switch():
- remove or adjust all useless 'break'.
- remove useless
On 04/01/2014 04:13 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
On 03/31/2014 11:49 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
in get_boot_device()
- remove 'res' to simplify code
in main():
- remove useless 'continue
On 04/01/2014 08:36 PM, Alex Bennée wrote:
Chen Gang gang.chen.5...@gmail.com writes:
Hello Maintainers:
In main switch of main(), it contents several styles for {...} code block.
If it is necessary to use unique style within a function, please let me
know, I will/should clean up
On 04/01/2014 09:33 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
On 04/01/2014 04:13 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
On 03/31/2014 11:49 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes
When you ask for an accelerator not supported for your target, you get
a bogus accelerator does not exist message:
$ qemu-system-arm -machine none,accel=kvm
KVM not supported for this target
kvm accelerator does not exist.
No accelerator found!
Suppress it.
Signed-off-by: Chen Gang
On 04/04/2014 06:57 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
When you ask for an accelerator not supported for your target, you get
a bogus accelerator does not exist message:
$ qemu-system-arm -machine none,accel=kvm
KVM not supported for this target
On 04/06/2014 02:32 PM, Michael Tokarev wrote:
04.04.2014 13:39, Chen Gang wrote:
When you ask for an accelerator not supported for your target, you get
a bogus accelerator does not exist message:
$ qemu-system-arm -machine none,accel=kvm
KVM not supported for this target
kvm
Thanks, and I will/should finish the left trivial patches within this
week (2014-04-13)
On 04/08/2014 03:04 PM, Michael Tokarev wrote:
From: Chen Gang gang.chen.5...@gmail.com
When you ask for an accelerator not supported for your target, you get
a bogus accelerator does not exist message
(...)).
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
Normal if (...) {...} else {...} is enough in while(...) {...}, not
need additional useless 'continue'.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c |1 -
1 file changed, 1 deletion(-)
diff --git a/vl.c b/vl.c
index 9975e5a..7505002 100644
--- a/vl.c
+++ b/vl.c
@@ -3034,7
In function, if no additional resources to free before quit, commonly,
need not use additional local variable 'res' to notice about it. So
remove it to simplify code.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
.
And at present, we can assume that all related gcc versions will be
latest enough to notice about this grammar.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/vl.c b/vl.c
index 377f962..d381443
May any member help to check them?
And next, I shall try to find bug issues (not code style or document
issues), and fix them. Hope I can succeed.
Thanks.
On 04/08/2014 08:00 PM, Chen Gang wrote:
In vl.c, at least, we can simplify the code below, so can let readers
read professional C code
On 04/15/2014 10:11 AM, Peter Crosthwaite wrote:
On Tue, Apr 8, 2014 at 10:01 PM, Chen Gang gang.chen.5...@gmail.com wrote:
Normal if (...) {...} else {...} is enough in while(...) {...}, not
need additional useless 'continue'.
Only in the case where the if-else is not followed by any code
On 04/15/2014 10:13 AM, Peter Crosthwaite wrote:
On Tue, Apr 8, 2014 at 10:02 PM, Chen Gang gang.chen.5...@gmail.com wrote:
In function, if no additional resources to free before quit, commonly,
need not use additional local variable 'res' to notice about it. So
remove it to simplify code
On 04/15/2014 04:43 PM, Markus Armbruster wrote:
Peter Crosthwaite peter.crosthwa...@xilinx.com writes:
On Tue, Apr 8, 2014 at 10:02 PM, Chen Gang gang.chen.5...@gmail.com wrote:
In function, if no additional resources to free before quit, commonly,
need not use additional local variable
On 04/15/2014 04:50 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
Normal if (...) {...} else {...} is enough in while(...) {...}, not
need additional useless 'continue'.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c |1 -
1 file changed, 1
On 04/15/2014 04:56 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
For C code, it does not recommend to define a local variable in the
middle of code block without {...}. The original author may want to
zero members not mentioned in structure assignment.
So
On 04/15/2014 08:29 PM, Peter Crosthwaite wrote:
On Tue, Apr 8, 2014 at 10:05 PM, Chen Gang gang.chen.5...@gmail.com wrote:
For C code, it does not recommend to define a local variable in the
middle of code block without {...}. The original author may want to
zero members not mentioned
On 04/15/2014 04:49 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
In vl.c, at least, we can simplify the code below, so can let readers
read professional C code (especially for new readers, which often start
reading code at main function).
- remove useless
On 04/15/2014 10:51 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
On 04/15/2014 04:49 PM, Markus Armbruster wrote:
In future submissions, please send the patches in-reply-to the cover
letter, not chained together in-reply-to the previous part. Check out
git-send
In vl.c, at least, we can simplify the code below, so can let readers
read professional C code (especially for new readers, which often start
reading code at main function).
- Remove useless 'continue' in main().
- Eliminate a superfluous local variable in main().
Signed-off-by: Chen Gang
This if else has no code between it and the end of the enclosing
while loop. This makes this continue redundant.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c |1 -
1 file changed, 1 deletion(-)
diff --git a/vl.c b/vl.c
index 9975e5a..7505002 100644
--- a/vl.c
+++ b/vl.c
CODING_STYLE frowns upon mixing declarations and statements. main()
has such a declaration. Clean up by eliminating the variable.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
vl.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/vl.c b/vl.c
'buf' is not used actually, so remove it and related snprintf() statement.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
block.c | 2 --
dtc | 1 -
2 files changed, 3 deletions(-)
delete mode 16 dtc
diff --git a/block.c b/block.c
index 43abe96..74af8d7 100644
--- a/block.c
When failure occurs, 'ret' need be set, or may return 0 to indicate success.
And error_propagate() also need be called only one time within a function.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block.c b
On 06/21/2014 11:03 PM, Michael Tokarev wrote:
21.06.2014 17:00, Chen Gang wrote:
'buf' is not used actually, so remove it and related snprintf() statement.
Applied to -trivial, after removing wrong reference to dtc submodule removal.
Please don't include these in diffs.
OK, thanks, I
;
}
}
That's fine to me, I shall send patch v2 for it.
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed
internally.
So let bdrv_append_temp_snapshot() internal return value outside, and let
all things normal, then fix the issue too.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
block.c | 7 ---
include/block/block.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions
On 06/24/2014 10:25 AM, Fam Zheng wrote:
On Mon, 06/23 23:28, Chen Gang wrote:
When failure occurs, 'ret' need be set, or may return 0 to indicate success.
s/need/needs/
And error_propagate() also need be called only one time within a function.
s/need/needs/
For a grammar in my
Thank you for all of your work, if necessary to send patch v3 for it
(may change the comments), please let me know.
Thanks.
On 06/25/2014 12:00 AM, Michael Tokarev wrote:
24.06.2014 15:01, Markus Armbruster wrote:
Kevin Wolf kw...@redhat.com writes:
Am 23.06.2014 um 17:28 hat Chen Gang
the related checking statements, and also can remove 'rc'
and 'ret' local variables,
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
arch_init.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 60c975d..98ee5b6 100644
On 05/17/2014 03:54 PM, Michael Tokarev wrote:
10.05.2014 16:51, Chen Gang wrote:
For xbzrle_decode_buffer(), when decoding contents will exceed writing
buffer, it will return -1, so need not check the return value whether
large than writing buffer.
And when failure occurs within load_xbzrle
On 02/05/2014 07:44 AM, Chen Gang wrote:
On 02/05/2014 12:18 AM, Aneesh Kumar K.V wrote:
That is a bug. The snprintf usage with PATH_MAX is to prevent buffer
overflow and not to truncate. I guess we should fix path handling
and propagate error correctly.
-aneesh
OK, thank you for your
this path.
mkdir -p, create/open file/dir, modify file/dir, rm file/dir.
change various mount point paths under host and/or guest.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
hw/9pfs/cofs.c | 22 ++-
hw/9pfs/virtio-9p-handle.c | 25 ++-
hw/9pfs/virtio-9p
During the test, I found that if the path is long, the performance is
very very slow under 9pfs (whether apply this patch or not, the results
are the same).
So after this patch passes checking, I will/should analyse this
performance issue, next.
Thanks.
On 02/23/2014 12:48 PM, Chen Gang wrote
.
Next weekend should be fine. Happy hacking!
OK, thank you.
Thanks
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Patch 1/3: move v9fs_string_free() to below err_out:
Patch 2/3: use snprintf() instead of sprintf()
(which will be replaced of by Path 3/3)
Patch 3/3: use g_strdup_printf() instead of PATH_MAX limitation
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
hw/9pfs/cofs.c
When goto err_out, 'v9fs_string' already was allocated, so still need
free 'v9fs_string' before return.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
hw/9pfs/virtio-9p-local.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio
'ctx-fs_root' + 'path'/'fullname.data' may be larger than PATH_MAX, so
need use snprintf() instead of sprintf() just like another area have done in
9pfs.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
hw/9pfs/virtio-9p-local.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions
denied).
- Common test:
All are still OK after apply this path.
mkdir -p, create/open file/dir, modify file/dir, rm file/dir.
change various mount point paths under host and/or guest.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
hw/9pfs/cofs.c | 15
On 03/03/2014 04:34 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
When path is truncated by PATH_MAX limitation, it causes QEMU to access
incorrect file. So use original full path instead of PATH_MAX within
9pfs (need check/process ENOMEM for related memory
On 03/03/2014 04:34 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
'ctx-fs_root' + 'path'/'fullname.data' may be larger than PATH_MAX, so
need use snprintf() instead of sprintf() just like another area have done in
9pfs.
Signed-off-by: Chen Gang gang.chen.5
On 03/03/2014 11:29 PM, Aneesh Kumar K.V wrote:
Chen Gang gang.chen.5...@gmail.com writes:
When goto err_out, 'v9fs_string' already was allocated, so still need
free 'v9fs_string' before return.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
Reviewed-by: Aneesh Kumar K.V aneesh.ku
On 03/04/2014 03:29 AM, Aneesh Kumar K.V wrote:
Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com writes:
Chen Gang gang.chen.5...@gmail.com writes:
Can we keep this as
v9fs_co_run_in_worker(
{
buf-data = __readlink(s-ctx, path
On 03/03/2014 10:42 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
On 03/03/2014 04:34 PM, Markus Armbruster wrote:
Turns a buffer overrun bug into a truncation bug. The next commit fixes
truncation bugs including this one. Would be nice to spell this out
On 03/04/2014 01:43 AM, Eric Blake wrote:
On 03/01/2014 10:33 AM, Chen Gang wrote:
Patch 1/3: move v9fs_string_free() to below err_out:
Patch 2/3: use snprintf() instead of sprintf()
(which will be replaced of by Path 3/3)
Patch 3/3: use g_strdup_printf() instead of PATH_MAX
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use snprintf() instead of sprintf().
And also recommend to use ARRAY_SIZE instead of hard code macro for an
array size in snprintf().
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
hw/9pfs/virtio-9p-local.c | 9
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use snprintf() instead of sprintf().
And also recommend to use ARRAY_SIZE instead of hard code macro
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' + 'ctx-fs_root' must be less than MAX_PATH,
so need use snprintf() instead of sprintf().
And also recommend to use
On 02/04/2014 07:06 PM, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 07:02:18PM +0800, Chen Gang wrote:
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote:
On Mon, Feb 03, 2014 at 06:00:42PM +0800, Chen Gang wrote:
We can not assume 'path' + 'ctx
features -- support 'unlimited' path internally.
before do it, better to get original authors' response firstly.
I guess, we need change quite a few areas and have a full test.
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
On 02/05/2014 12:18 AM, Aneesh Kumar K.V wrote:
Chen Gang gang.chen.5...@gmail.com writes:
On 02/04/2014 07:06 PM, Daniel P. Berrange wrote:
On Tue, Feb 04, 2014 at 07:02:18PM +0800, Chen Gang wrote:
On 02/03/2014 06:39 PM, Chen Gang wrote:
On 02/03/2014 06:34 PM, Daniel P. Berrange wrote
After finish 'writeconfig' to stdout (with '-'), we want to copy/past
the related information mannually, not for redirection ('readconfig'
does not support '-').
So we can not close the stdout, or next options which may use stdout
will not be displayed.
Signed-off-by: Chen Gang gang.chen.5
On 04/21/2014 11:09 PM, Eric Blake wrote:
On 04/20/2014 06:05 AM, Chen Gang wrote:
After finish 'writeconfig' to stdout (with '-'), we want to copy/past
the related information mannually, not for redirection ('readconfig'
does not support '-').
So we can not close the stdout, or next
from '-')
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
vl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/vl.c b/vl.c
index 9975e5a..215467f 100644
--- a/vl.c
+++ b/vl.c
@@ -3855,7 +3855,9 @@ int main(int argc, char **argv
When DPRINTF() has effect, the original author wants to print all
ram_load() calling results. So need use 'goto' instead of 'return'
within ram_load(), just like other areas have done.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
arch_init.c | 12
1 file changed, 8
.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
arch_init.c | 1 -
page_cache.c | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch_init.c b/arch_init.c
index 9f1a174..23044c1 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -739,7 +739,6 @@ static void migration_end(void
'encoded_buf' and 'current_buf' are lock protected during using in
save_xbzrle_page() in ram_save_page(), and during freeing in
migration_end().
So recommend to let them lock protected during starting, just like we
have done to 'cache'.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
Firstly, thank you very much for reviewing the related 2 patches.
On 06/03/2014 03:31 PM, ChenLiang wrote:
On 2014/6/2 20:35, Chen Gang wrote:
'encoded_buf' and 'current_buf' are lock protected during using in
save_xbzrle_page() in ram_save_page(), and during freeing in
migration_end
On 06/04/2014 04:16 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
Call g_free() after cache_fini() in migration_end(), but do not call
g_free() after call cache_fini() in xbzrle_cache_resize() which will
cause memory leak.
cache_init() and cache_fini() are pair
On 06/04/2014 04:20 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
'encoded_buf' and 'current_buf' are lock protected during using in
save_xbzrle_page() in ram_save_page(), and during freeing in
migration_end().
So recommend to let them lock protected during
Firstly, thank you very much for reviewing the related 2 patches.
On 06/04/2014 06:01 PM, Dr. David Alan Gilbert wrote:
* Chen Gang (gang.chen.5...@gmail.com) wrote:
Firstly, thank you very much for reviewing the related 2 patches.
On 06/03/2014 03:31 PM, ChenLiang wrote:
On 2014/6/2 20
On 06/04/2014 06:54 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
On 06/04/2014 04:16 PM, Markus Armbruster wrote:
Chen Gang gang.chen.5...@gmail.com writes:
Call g_free() after cache_fini() in migration_end(), but do not call
g_free() after call cache_fini
for it.
Thanks.
On 03/07/2014 11:16 PM, Aneesh Kumar K.V wrote:
From: Chen Gang gang.chen.5...@gmail.com
When path is truncated by PATH_MAX limitation, it causes QEMU to access
incorrect file. So use original full path instead of PATH_MAX within
9pfs (need check/process ENOMEM for related memory
On 03/08/2014 09:58 PM, Chen Gang wrote:
OK, thanks.
Next, I will/should continue to analyse the performance issue for 9pfs
when users drop into a long directory path under bash shell.
After have a test, I am sure it is not 9pfs issue, either not Qemu's
issue, it's Linux kernel vfs or block
Clean up useless 'break' statement after 'return' statement.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
target-arm/gdbstub64.c |2 --
1 file changed, 2 deletions(-)
diff --git a/target-arm/gdbstub64.c b/target-arm/gdbstub64.c
index e8a8295..8f3b8d1 100644
--- a/target-arm
On 03/18/2014 08:39 AM, Peter Maydell wrote:
On 18 March 2014 00:31, Chen Gang gang.chen.5...@gmail.com wrote:
Clean up useless 'break' statement after 'return' statement.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
thanks
-- PMM
On 03/18/2014 01:14 PM, Peter Crosthwaite wrote:
On Tue, Mar 18, 2014 at 10:31 AM, Chen Gang gang.chen.5...@gmail.com wrote:
Clean up useless 'break' statement after 'return' statement.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
Reviewed-by: Peter Crosthwaite peter.crosthwa
On 03/16/2014 09:32 PM, Chen Gang wrote:
On 03/08/2014 09:58 PM, Chen Gang wrote:
OK, thanks.
Next, I will/should continue to analyse the performance issue for 9pfs
when users drop into a long directory path under bash shell.
After have a test, I am sure it is not 9pfs issue, either
In this case, 'ret' is already '-1', so need not do it again.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
qemu-img.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/qemu-img.c b/qemu-img.c
index c98896b..d4518e7 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -246,7 +246,6 @@ static int
getchar() is a standard c library function which may return with failure
(e.g. -1), so like another platforms, also need check it under WIN32.
And make the related code match current qemu code styles, too.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
qemu-img.c | 10 --
1 file
On 07/09/2014 09:58 PM, Michael Tokarev wrote:
03.07.2014 17:57, Chen Gang wrote:
In this case, 'ret' is already '-1', so need not do it again.
It's a very minor thing in an error path, maybe compiler even
eliminates this statement entirely by its own already.
Yeah, normal compiler
temporary variable for 'cpu' to avoid the case.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
kvm-all.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 3ae30ee..1402f4f 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -2077,12 +2077,13 @@ void
On 07/20/2014 03:29 PM, Jan Kiszka wrote:
On 2014-07-19 03:21, Chen Gang wrote:
If kvm_arch_remove_sw_breakpoint() in CPU_FOREACH() always be fail, it
will let 'cpu' NULL. And the next kvm_arch_remove_sw_breakpoint() in
QTAILQ_FOREACH_SAFE() will get NULL parameter for 'cpu
By the way, at present, I use Qemu as user mode program, is there common
test with both Qemu and KVM/Xen? And is a PC enough for the common test?
Thanks.
On 08/20/2014 07:58 AM, Chen Gang wrote:
On 08/19/2014 11:49 PM, Paolo Bonzini wrote:
Il 19/08/2014 17:44, Chen Gang ha scritto:
Hello
On 08/20/2014 08:01 AM, Chen Gang wrote:
By the way, at present, I use Qemu as user mode program, is there common
test with both Qemu and KVM/Xen? And is a PC enough for the common test?
Oh, I find Qemu have make check just like gcc/binutils, so for each of
my patch, next, shall run
check
execute result: echo $? == 0.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
xen-hvm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen-hvm.c b/xen-hvm.c
index 0d09940..35efec0 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -978,6 +978,7 @@ static void
Oh, sorry, forgot Cc to qemu trivial.
Thanks.
On 9/3/14 0:22, Chen Gang wrote:
When failure occurs, it need use return -1 instead of exit(1), so can
let upper caller has chance to print failure information, too, then user
can know the failure result more clearly.
xen_hvm_init() may also
1 - 100 of 614 matches
Mail list logo
