| Message ID | 533E7DD5.3090203@gmail.com |
|---|---|
| State | New |
| Headers | show |
Chen Gang <gang.chen.5i5j@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 <gang.chen.5i5j@gmail.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
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" accelerator does not exist. > No accelerator found! > > Suppress it. Applied to -trivial, thanks! /mjt
On 04/04/2014 06:57 PM, Markus Armbruster wrote: > Chen Gang <gang.chen.5i5j@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 <gang.chen.5i5j@gmail.com> > > Reviewed-by: Markus Armbruster <armbru@redhat.com> > Thanks.
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" accelerator does not exist. >> No accelerator found! >> >> Suppress it. > > Applied to -trivial, thanks! > > /mjt > Thanks !
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().
- remove redundant local variable 'res' in get_boot_device().
- remove local variable 'args' in the middle of code block in main().
The following 3 patches are for the 3 'remove' above.
And "vl.c" has a very long function main() which is about 17K lines.
Next, it can be split into sub-functions (so can bypass another code
style issue: multiple "{...}" styles within "swith(...)").
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
vl.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
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 (especially for new readers, which often start > reading code at main function). > > - remove useless 'continue' in main(). > > - remove redundant local variable 'res' in get_boot_device(). > > - remove local variable 'args' in the middle of code block in main(). > > The following 3 patches are for the 3 'remove' above. > > And "vl.c" has a very long function main() which is about 17K lines. > Next, it can be split into sub-functions (so can bypass another code > style issue: multiple "{...}" styles within "swith(...)"). > > > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> > --- > vl.c | 23 ++++++++++------------- > 1 file changed, 10 insertions(+), 13 deletions(-) >
Chen Gang <gang.chen.5i5j@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 'continue' in main(). > > - remove redundant local variable 'res' in get_boot_device(). > > - remove local variable 'args' in the middle of code block in main(). > > The following 3 patches are for the 3 'remove' above. > > And "vl.c" has a very long function main() which is about 17K lines. > Next, it can be split into sub-functions (so can bypass another code > style issue: multiple "{...}" styles within "swith(...)"). > > > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> > --- > vl.c | 23 ++++++++++------------- > 1 file changed, 10 insertions(+), 13 deletions(-) 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-email --no-chain-reply-to.
On 04/15/2014 04:49 PM, Markus Armbruster wrote: > Chen Gang <gang.chen.5i5j@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 'continue' in main(). >> >> - remove redundant local variable 'res' in get_boot_device(). >> >> - remove local variable 'args' in the middle of code block in main(). >> >> The following 3 patches are for the 3 'remove' above. >> >> And "vl.c" has a very long function main() which is about 17K lines. >> Next, it can be split into sub-functions (so can bypass another code >> style issue: multiple "{...}" styles within "swith(...)"). >> >> >> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> >> --- >> vl.c | 23 ++++++++++------------- >> 1 file changed, 10 insertions(+), 13 deletions(-) > > 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-email --no-chain-reply-to. > OK, thanks. But excuse me, I use thunderbird client to send/recv mail (not use git send-mail), so not quit understand what you said. And I guess what your meaning is: - start a new thread "[PATH 0/3]..." - "[PATH 1/3]..." need "reply all" the "[PATH 0/3]..." - "[PATH 2/3]..." need "reply all" the "[PATH 0/3]..." - "[PATH 3/3]..." need "reply all" the "[PATH 0/3]..." If what I guess is incorrect, please let me know, and it will be better to provide more detials. Thanks.
Chen Gang <gang.chen.5i5j@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-email --no-chain-reply-to. >> > > OK, thanks. But excuse me, I use thunderbird client to send/recv mail > (not use git send-mail), so not quit understand what you said. And I > guess what your meaning is: > > - start a new thread "[PATH 0/3]..." > > - "[PATH 1/3]..." need "reply all" the "[PATH 0/3]..." > > - "[PATH 2/3]..." need "reply all" the "[PATH 0/3]..." > > - "[PATH 3/3]..." need "reply all" the "[PATH 0/3]..." > > If what I guess is incorrect, please let me know, and it will be better > to provide more detials. Sounds okay. But sending with git-send-email is so much easier...
On 04/15/2014 10:51 PM, Markus Armbruster wrote: > Chen Gang <gang.chen.5i5j@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-email --no-chain-reply-to. >>> >> >> OK, thanks. But excuse me, I use thunderbird client to send/recv mail >> (not use git send-mail), so not quit understand what you said. And I >> guess what your meaning is: >> >> - start a new thread "[PATH 0/3]..." >> >> - "[PATH 1/3]..." need "reply all" the "[PATH 0/3]..." >> >> - "[PATH 2/3]..." need "reply all" the "[PATH 0/3]..." >> >> - "[PATH 3/3]..." need "reply all" the "[PATH 0/3]..." >> >> If what I guess is incorrect, please let me know, and it will be better >> to provide more detials. > > Sounds okay. But sending with git-send-email is so much easier... > I guess so, too (sending with git-send-email is much easier, which I am not quite familiar). I have already familiar with Thunderbird, and at least now, I am not a maintainer, neither a main patch maker. at present, I have no too many patches to process. So Thunderbird is enough to me. :-) Thanks.
diff --git a/vl.c b/vl.c index 842e897..b4f98fa 100644 --- a/vl.c +++ b/vl.c @@ -2709,7 +2709,7 @@ static int configure_accelerator(QEMUMachine *machine) if (!accel_list[i].available()) { printf("%s not supported for this target\n", accel_list[i].name); - continue; + break; } *(accel_list[i].allowed) = true; ret = accel_list[i].init(machine);
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 <gang.chen.5i5j@gmail.com> --- vl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)