On Thu, 22 Aug 2013 17:16:23 +0800
Wenchao Xia <xiaw...@linux.vnet.ibm.com> wrote:
> δΊ 2013-8-20 22:04, Luiz Capitulino ει:
> > On Tue, 30 Jul 2013 12:03:11 -0400
> > Luiz Capitulino <lcapitul...@redhat.com> wrote:
> >
> >> On Fri, 26 Jul 2013 11:20:29 +0800
> >> Wenchao Xia <xiaw...@linux.vnet.ibm.com> wrote:
> >>
> >>> This series make auto completion and help functions works normal for sub
> >>> command, by using reentrant functions. In order to do that, global
> >>> variables
> >>> are not directly used in those functions any more. With this series,
> >>> cmd_table
> >>> is a member of structure Monitor so it is possible to create a monitor
> >>> with
> >>> different command table now, auto completion will work in that monitor. In
> >>> short, "info" is not treated as a special case now, this series ensure
> >>> help
> >>> and auto complete function works normal for any sub command added in the
> >>> future.
> >>>
> >>> Patch 5 replaced cur_mon with rs->mon, it is safe because:
> >>> monitor_init() calls readline_init() which initialize mon->rs, result is
> >>> mon->rs->mon == mon. Then qemu_chr_add_handlers() is called, which make
> >>> monitor_read() function take *mon as its opaque. Later, when user input,
> >>> monitor_read() is called, where cur_mon is set to *mon by "cur_mon =
> >>> opaque".
> >>> If qemu's monitors run in one thread, then later in readline_handle_byte()
> >>> and readline_comletion(), cur_mon is actually equal to rs->mon, in another
> >>> word, it points to the monitor instance, so it is safe to replace *cur_mon
> >>> in those functions.
> >>
> >> I've applied this to qmp-next with the change I suggested for
> >> patch 09/13.
> >
> > Unfortunately this series brakes make check:
> >
> > GTESTER check-qtest-x86_64
> > Broken pipe
> > GTester: last random seed: R02S3492bd34f44dd17460851643383be44d
> > main-loop: WARNING: I/O thread spun for 1000 iterations
> > make: *** [check-qtest-x86_64] Error 1
> >
> > I debugged it (with some help from Laszlo) and the problem is that it
> > broke the human-monitor-command command. Any usage of this command
> > triggers the bug like:
> >
> > { "execute": "human-monitor-command",
> > "arguments": { "command-line": "info registers" } }
> >
> > It seems simple to fix, I think you just have to initialize
> > mon->cmd_table in qmp_human_monitor_command(), but I'd recommend two
> > things:
> >
> > 1. It's better to split off some/all QMP initialization from
> > monitor_init() and call it from qmp_human_monitor_command()
> >
> > 2. Can you please take the opportunity and test all commands using
> > cur_mon? Just grep for it
> >
> > Sorry for noticing this only now, but I only run make check before
> > sending a pull request (although this very likely shows you didn't
> > run it either).
> >
> About the fd related qmp interface, to test it, send_msg() is needed,
> which was not supported in python 2, but new added python 3.3. I think
> there are three ways to add test cases for fd qmp APIs:
> 1 test only when python > 3.3.
> 2 python plus C: compile a .so and call it with ctypes.
> 3 a new test framework: pure C code to call qmp interfaces.
> Which one do you prefer?
Can't we have a C program plus a shell script to test this? Anyway, if
this gets complicated you can skip having the test-case. This series took
a long way already and holding it because of that test-case isn't fair.
