'buf' is not used actually, so remove it and related snprintf() statement.
Signed-off-by: Chen Gang
---
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
+++ b/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
---
block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block.c b/block.c
ind
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'
local_err);
> goto close_and_fail;
> }
> }
>
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
turn value 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
---
block.c | 7 ---
include/block/block.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a
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.
&g
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
>&
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).
>>
>> Als
On 08/15/2014 04:49 AM, Luiz Capitulino wrote:
> On Sun, 03 Aug 2014 23:28:56 +0800
> 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
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 h
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
related checking statements, and also can remove 'rc'
and 'ret' local variables,
Signed-off-by: Chen Gang
---
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
--- a/arch_init
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.
>>
>&g
ructions-a64.h:119:20: error: 'vixl::kFP32DefaultNaN'
defined but not used [-Werror=unused-variable]
static const float kFP32DefaultNaN = rawbits_to_float(0x7fc0);
^
cc1plus: all warnings being treated as errors
make: *** [disas/arm-a64.o] Error 1
Signed-
On 10/9/14 22:54, Eric Blake wrote:
> On 10/09/2014 08:00 AM, Chen Gang wrote:
>
> That's a very long subject line. Try to keep subjects around 60
> characters or so ('git shortlog -30' can give you an idea of reasonable
> subjects).
OK, thanks, I shall notic
On 10/9/14 22:34, Peter Maydell wrote:
> On 9 October 2014 15:00, Chen Gang wrote:
>> The related variables are useless, need be removed, or can not pass
>> microblaze building, after fix it, can build microblaze, successfully.
>>
>> The related configuration:
>&
On 10/10/14 15:37, Peter Maydell wrote:
> On 10 October 2014 02:54, Chen Gang wrote:
>> I use the latest upstream gcc (which pulled from master in 2014-10-0?).
>> In my memory (not quite sure), the older version gcc may not notice
>> about this warning.
>
> Hmm. I
On 10/10/14 16:53, Chen Gang wrote:
> On 10/10/14 15:37, Peter Maydell wrote:
>>>> The reason I'm reluctant to make changes to these files is
>>>> that they're pulled in from a different upstream project
>>>> (libvixl) so we should only fix critica
g treated as errors
make: *** [disas/arm-a64.o] Error 1
After this patch, can pass upstream gcc 5.0.0 building (print warning,
but not break building), and fedora 20 gcc 4.8.1 building (not find
warnings).
Signed-off-by: Chen Gang
---
disas/libvixl/a64/instructions-a64.h | 9 +
1 file c
On 10/11/14 22:07, Chen Gang wrote:
> 'instructions-a64.h' has unused variables for qemu which can be found by
> gcc 5.0.0 or higher. and qemu needs "-Werror", and cause building break.
> But they may be used by another projects (not qemu).
>
> So for gcc 5.
On 10/12/14 5:25, Peter Maydell wrote:
> On 11 October 2014 15:13, Chen Gang wrote:
>
> MJT: please don't put this in -trivial, it will clash with
> the update to libvixl 1.6 currently on the list.
>
OK thanks (also remove -trivial from replying mailing list).
>
>
On 10/12/14 15:50, Peter Maydell wrote:
> On 12 October 2014 01:32, Chen Gang wrote:
>> On 10/12/14 5:25, Peter Maydell wrote:
>>> Some other approaches to this that would confine the
>>> fix to the makefiles rather than requiring us to modify
>>> the vi
strncat() will append additional '\0' to destination buffer, so need
additional 1 byte for it, or may cause memory overflow, just like other
area within QEMU have done.
Signed-off-by: Chen Gang
---
target-ppc/kvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
/%s", buf, propname);
-f = fopen(buf, "rb");
+f = fopen(tmp, "rb");
+g_free(buf);
if (!f) {
return -1;
}
For me, it is really a personal taste, so if the maintainer feels the
diff above is OK, I shall send patch v2 for it within 2 days.
Th
On 10/15/2014 03:58 AM, Michael Tokarev wrote:
> On 11.10.2014 23:25, Peter Maydell wrote:
>> On 11 October 2014 15:13, Chen Gang wrote:
>>
>> MJT: please don't put this in -trivial, it will clash with
>> the update to libvixl 1.6 currently on the list.
>
>
On 10/15/14 4:47, Chen Gang wrote:
> On 10/15/2014 03:58 AM, Michael Tokarev wrote:
>>
>> That's what I'm after too (after trying to fix it properly).
>> And no, at this time I dont know how gcc5 handles this.
>>
>
> At present, I have sent the related
strncat() will append additional '\0' to destination buffer, so need
additional 1 byte for it, or may cause memory overflow, just like other
area within QEMU have done.
And can use g_strdup_printf() instead of strncat(), which may be more
easier understanding.
Signed-off-by:
microblaze_complete.cpio.gz
- result:
Segmentation fault (core dumped) (after a simple try, I am sure, it is
caused by "dtb").
And excuse me, at present, I have to only focus on fixing upstream qemu
issues (I have no enough time resource for other qemu branches), please
understand.
Thanks.
On 10/19/14 21:38, Max Filippov wrote:
> On Sun, Oct 19, 2014 at 5:37 PM, Chen Gang wrote:
>>- running:
>>
>> ./arm-softmmu/qemu-system-arm -M arm-generic-fdt -nographic -smp 2
>> -machine linux=on -serial mon:stdio -dtb ../linux-xlnx/system.dtb \
>>
OK, thanks, I shall try it within 2 days.
Send from Lenovo A788t.
Guenter Roeck wrote:
>On 10/19/2014 06:58 AM, Chen Gang wrote:
>>
>> On 10/19/14 21:38, Max Filippov wrote:
>>> On Sun, Oct 19, 2014 at 5:37 PM, Chen Gang wrote:
>>>> - running:
>>&
fc20 20140613
Welcome any suggestions or completions.
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed
On 10/21/14 12:37, Guenter Roeck wrote:
> On 10/20/2014 08:23 AM, Chen Gang wrote:
>> On 10/19/2014 10:58 PM, Guenter Roeck wrote:
>>>
>>> This doesn't use devicetree, but the configurations are known to be working
>>> with kernel releases all the way ba
Good news for us! thank you for your work. :-)
Thanks
Send from Lenovo A788t.
Peter Maydell wrote:
>On 9 October 2014 15:00, Chen Gang wrote:
>> The related variables are useless, need be removed, or can not pass
>> microblaze building, after fix it, can build microblaz
21, 2014 at 06:41:14PM +0800, Chen Gang wrote:
>> On 10/21/14 12:37, Guenter Roeck wrote:
>> > On 10/20/2014 08:23 AM, Chen Gang wrote:
>> >> On 10/19/2014 10:58 PM, Guenter Roeck wrote:
>> >>>
>> >>> This doesn't use devicetree, but the
On 10/24/14 15:49, Michael Tokarev wrote:
> On 10/13/2014 06:47 PM, Alexander Graf wrote:
>> On 13.10.14 16:36, Chen Gang wrote:
>>> strncat() will append additional '\0' to destination buffer, so need
>>> additional 1 byte for it, or may cause memory over
And I still shall try qemu and kernel distribution for testing.
But excuse me, maybe I can not finish within this month, I shall try to
finish within next month.
Thanks.
发自我的 iPad
> 在 2014年10月22日，上午8:28，Chen Gang 写道：
>
> OK, thanks, there are multiple branches in upstream qemu. So
Thank your information about qemu, again.
Thanks.
On 10/22/2014 08:28 AM, Chen Gang wrote:
> OK, thanks, there are multiple branches in upstream qemu. Sorry
> for my original said, and I can only say: for upstream develop
> master branch, it does not support microblaze.
>
> Excuse me, I
On 10/26/14 21:28, Chen Gang wrote:
> Hello Guenter Roeck:
>
> I still shall try qemu and kernel distribution, next, since it can do
> it successfully (whether 'sim' can be success or not).
>
I got confirmation from microblaze members, at present, microblaze sim
can
rsion 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)"
for x86_64 qemu.
Next I shall try to use virtio file to share the local data to virtual
guest (I guess, it should be OK).
Thanks again!
On 10/27/2014 09:47 AM, Chen Gang wrote:
> On 10/26/14 21:28, Chen Gang wrote:
>> Hello Guenter
On 10/27/14 22:47, Chen Gang wrote:
>
> After a little try, I succeed run microblaze under upstream qemu 2.1.2
> and upstream Linux kernel 3.17-rc7, with the xilinux own ramdisk:
> "microblaze_complete.cpio.gz". :-)
>
> Compiler is "gcc version 4.9.1 20140717 (Re
-ethernetlite-3.00.a", },
{ /* end of list */ },
Next, I shall send related kernel patch for upstream kernel, and continue
for microbaze DejaGNU with microbaze qemu, and sorry again, I did not
finish it within this month.
Thanks.
On 10/30/14 22:20, Chen Gang wrote:
> O
;
edit work.dts (replace 'xlnx,xps-ethernetlite-2.00.b')
"./scripts/dtc/dtc -I dts -O dtb -o ..qemu/petalogix-s3adsp1800.dtb
../work.dts"
(Since I am not quite sure whether can read this patch or not, I put the
related dtb file in attachment, please check, thanks).
Sign
xen && make -j4 && make check"
execute result: "echo $? == 0".
Signed-off-by: Chen Gang
---
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
@@ -9
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.
>
On 9/4/14 7:32, Stefano Stabellini wrote:
> On Wed, 3 Sep 2014, Chen Gang wrote:
>> On 9/3/14 0:22, Chen Gang wrote:
[...]
>>> xen_hvm_init() may also return -errno, which may let upper caller think
>>> more (e.g. free some other related resources and try again), a
r failure.
It is not a normal function, it does not release related resources when
return -1, so need give related comments for it.
It passes common check:
"./configure --enable-xen && make && make check"
"echo $? == 0"
Signed-off-by: Chen Gang
---
xen
ope I can find additonal patches for
it.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
ope I can find additional patches for
it.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
ULL,
so need define additional temporary variable for 'cpu' to avoid the case.
Signed-off-by: Chen Gang
---
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
+++
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
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
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-b
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 (
tice
about soon.
By the way, in honest, as a gmail member, I almost do not check my email
in open mailing list, but always check personal mail which for sending
patches.
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed
t; Ccing you for the patches with which you have absolutely nothing
>> to do, and if a discussion emerges, you can't opt out of it
>> anymore (especially for patches which raise hot discussions).
>> So I'd rather think twice before contributing anything...
>
> That's sad.
>
--
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 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, a
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
er 'break'
within the matching block).
After print "... not support for this target", it can avoid to print
"... accelerator does not exist".
Signed-off-by: Chen Gang
---
vl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vl.c b
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 dro
On 03/27/2014 04:59 PM, Markus Armbruster wrote:
> Chen Gang 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
'args'
(which is defined in the middle of code block).
Signed-off-by: Chen Gang
---
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,1
which style 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():
>
>- re
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 writes:
>>
>>> At present, each 'opt
On 03/31/2014 08:38 PM, Markus Armbruster wrote:
> Chen Gang 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 mes
On 03/31/2014 09:01 PM, Peter Maydell wrote:
> On 31 March 2014 13:53, Chen Gang wrote:
>> On 03/31/2014 08:38 PM, Markus Armbruster wrote:
>>> Chen Gang writes:
>>>
>>>> Hello Maintainers:
>>>>
>>>> If it is necessary to s
On 03/31/2014 09:16 PM, Peter Maydell wrote:
> On 31 March 2014 14:12, Chen Gang 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 d
On 03/31/2014 09:33 PM, Peter Maydell wrote:
> On 31 March 2014 14:26, Chen Gang 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-dev
On 03/31/2014 11:49 PM, Markus Armbruster wrote:
> Chen Gang writes:
>
>> in get_boot_device()
>>
>> - remove 'res' to simplify code
>>
>> in main():
>>
>> - remove useless 'continue'.
>>
>> - in main switch():
&g
On 04/01/2014 04:13 PM, Markus Armbruster wrote:
> Chen Gang writes:
>
>> On 03/31/2014 11:49 PM, Markus Armbruster wrote:
>>> Chen Gang writes:
>>>
>>>> in get_boot_device()
>>>>
>>>> - remove 'res' to simplify code
On 04/01/2014 08:36 PM, Alex Bennée wrote:
>
> Chen Gang 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 le
On 04/01/2014 09:33 PM, Markus Armbruster wrote:
> Chen Gang writes:
>
>> On 04/01/2014 04:13 PM, Markus Armbruster wrote:
>>> Chen Gang writes:
>>>
>>>> On 03/31/2014 11:49 PM, Markus Armbruster wrote:
>>>>> Chen Gang 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.
Sign
On 04/04/2014 06:57 PM, Markus Armbruster wrote:
> Chen Gang 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
>>
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
&
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
>
> When you ask for an accelerator not supported for your target, you get
> a bogus "accelerator does not exist"
ther code
style issue: multiple "{...}" styles within "swith(...)").
Signed-off-by: Chen Gang
---
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
---
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
@@ -
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
---
vl.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/vl.c b/
n the middle of code block.
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
---
vl.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/vl.c b/vl.c
index 377f962..d3814
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
> rea
On 04/15/2014 10:11 AM, Peter Crosthwaite wrote:
> On Tue, Apr 8, 2014 at 10:01 PM, Chen Gang wrote:
>> > Normal "if (...) {...} else {...}" is enough in "while(...) {...}", not
>> > need additional useless 'continue'.
>> >
> Only i
On 04/15/2014 10:13 AM, Peter Crosthwaite wrote:
> On Tue, Apr 8, 2014 at 10:02 PM, Chen Gang 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 simp
On 04/15/2014 04:43 PM, Markus Armbruster wrote:
> Peter Crosthwaite writes:
>
>> On Tue, Apr 8, 2014 at 10:02 PM, Chen Gang wrote:
>>> In function, if no additional resources to free before quit, commonly,
>>> need not use additional local variable 'res'
On 04/15/2014 04:50 PM, Markus Armbruster wrote:
> Chen Gang writes:
>
>> Normal "if (...) {...} else {...}" is enough in "while(...) {...}", not
>> need additional useless 'continue'.
>>
>> Signed-off-by: Chen Gang
>> ---
>
On 04/15/2014 04:56 PM, Markus Armbruster wrote:
> Chen Gang 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 ass
On 04/15/2014 08:29 PM, Peter Crosthwaite wrote:
> On Tue, Apr 8, 2014 at 10:05 PM, Chen Gang 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 mem
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
---
vl.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --
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 wrote:
>> For valid 'fd&#
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 correctl
r guest
(permission 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 Ga
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
me.
>
> 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
---
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
---
hw/9pfs/virtio-9p-local.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/9pfs/virtio-9p-local.c b/h
'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
---
hw/9pfs/virtio-9p-local.c | 7 ---
1 file changed, 4 insertions(+), 3 d
test1234567890file.log" under guest
(permission 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 gues
On 03/03/2014 04:34 PM, Markus Armbruster wrote:
> Chen Gang 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 memor
On 03/03/2014 04:34 PM, Markus Armbruster wrote:
> Chen Gang 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.
>
On 03/03/2014 11:29 PM, Aneesh Kumar K.V wrote:
> Chen Gang writes:
>
>> When "goto err_out", 'v9fs_string' already was allocated, so still need
>> free 'v9fs_string' before return.
>>
>> Signed-off-by: Chen Gang
>
> Reviewed-b
On 03/04/2014 03:29 AM, Aneesh Kumar K.V wrote:
> "Aneesh Kumar K.V" writes:
>
>> Chen Gang writes:
>> Can we keep this as
>> v9fs_co_run_in_worker(
>> {
>>
>>buf->data = __readlink(&am
1 - 100 of 620 matches
Mail list logo
