into the QAPI framework implementation.
For an in-depth introduction to the QAPI framework, please refer to
-docs/qapi-code-gen.txt. For documentation about the QMP protocol, please
-check the files in QMP/.
+docs/qapi-code-gen.txt. For documentation about the QMP protocol,
+start with docs/qmp-intro.txt.
== Overview ==
5. Printing to the terminal is discouraged for QMP commands, we do it here
because it's the easiest way to demonstrate a QMP command
-Now a little hack is needed. As we're still using the old QMP server we need
-to add the new command to its internal dispatch table. This step won't be
-required in the near future. Open the qmp-commands.hx file and add the
-following in the botton:
-
- {
- .name = "hello-world",
- .args_type = "",
- .mhandler.cmd_new = qmp_marshal_input_hello_world,
- },
-
You're done. Now build qemu, run it as suggested in the "Testing" section,
and then type the following QMP command:
2. The C implementation signature must follow the schema's argument ordering,
which is defined by the "data" member
-The last step is to update the qmp-commands.hx file:
-
- {
- .name = "hello-world",
- .args_type = "message:s?",
- .mhandler.cmd_new = qmp_marshal_input_hello_world,
- },
-
-Notice that the "args_type" member got our "message" argument. The character
-"s" stands for "string" and "?" means it's optional. This too must be ordered
-according to the C implementation and schema file. You can look for more
-examples in the qmp-commands.hx file if you need to define more arguments.
-
-Again, this step won't be required in the future.
-
Time to test our new version of the "hello-world" command. Build qemu, run it as
described in the "Testing" section and then send two commands:
=== Errors ===
QMP commands should use the error interface exported by the error.h header
-file. Basically, errors are set by calling the error_set() function.
+file. Basically, most errors are set by calling the error_setg() function.
Let's say we don't accept the string "message" to contain the word "love". If
it does contain it, we want the "hello-world" command to return an error:
{
if (has_message) {
if (strstr(message, "love")) {
- error_set(errp, ERROR_CLASS_GENERIC_ERROR,
- "the word 'love' is not allowed");
+ error_setg(errp, "the word 'love' is not allowed");
return;
}
printf("%s\n", message);
}
}
-The first argument to the error_set() function is the Error pointer to pointer,
-which is passed to all QMP functions. The second argument is a ErrorClass
-value, which should be ERROR_CLASS_GENERIC_ERROR most of the time (more
-details about error classes are given below). The third argument is a human
+The first argument to the error_setg() function is the Error pointer
+to pointer, which is passed to all QMP functions. The next argument is a human
description of the error, this is a free-form printf-like string.
Let's test the example above. Build qemu, run it as defined in the "Testing"
}
}
-As a general rule, all QMP errors should use ERROR_CLASS_GENERIC_ERROR. There
-are two exceptions to this rule:
+As a general rule, all QMP errors should use ERROR_CLASS_GENERIC_ERROR
+(done by default when using error_setg()). There are two exceptions to
+this rule:
1. A non-generic ErrorClass value exists* for the failure you want to report
(eg. DeviceNotFound)
want to report, hence you have to add a new ErrorClass value so that they
can check for it
-If the failure you want to report doesn't fall in one of the two cases above,
-just report ERROR_CLASS_GENERIC_ERROR.
+If the failure you want to report falls into one of the two cases above,
+use error_set() with a second argument of an ErrorClass value.
* All existing ErrorClass values are defined in the qapi-schema.json file
#
# Print a client provided string to the standard output stream.
#
-# @message: #optional string to be printed
+# @message: string to be printed
#
# Returns: Nothing on success.
#
.args_type = "message:s?",
.params = "hello-world [message]",
.help = "Print message to the standard output",
- .mhandler.cmd = hmp_hello_world,
+ .cmd = hmp_hello_world,
},
STEXI
=== User Defined Types ===
+FIXME This example needs to be redone after commit 6d32717
+
For this example we will write the query-alarm-clock command, which returns
information about QEMU's timer alarm. For more information about it, please
check the "-clock" command-line option.
#
# @clock-name: The alarm clock method's name.
#
-# @next-deadline: #optional The time (in nanoseconds) the next alarm will fire.
+# @next-deadline: The time (in nanoseconds) the next alarm will fire.
#
# Since: 1.0
##
6. You have to include the "qmp-commands.h" header file in qemu-timer.c,
otherwise qemu won't build
-The last step is to add the correspoding entry in the qmp-commands.hx file:
-
- {
- .name = "query-alarm-clock",
- .args_type = "",
- .mhandler.cmd_new = qmp_marshal_input_query_alarm_clock,
- },
-
Time to test the new command. Build qemu, run it as described in the "Testing"
section and try this:
.args_type = "",
.params = "",
.help = "show information about the alarm clock",
- .mhandler.info = hmp_info_alarm_clock,
+ .cmd = hmp_info_alarm_clock,
},
To test this, run qemu and type "info alarmclock" in the user monitor.
to an TimerAlarmMethod instance.
Notice that the "current" variable is used as "true" only in the first
-interation of the loop. That's because the alarm timer method in use is the
+iteration of the loop. That's because the alarm timer method in use is the
first element of the alarm_timers array. Also notice that QAPI lists are handled
by hand and we return the head of the list.
-To test this you have to add the corresponding qmp-commands.hx entry:
-
- {
- .name = "query-alarm-methods",
- .args_type = "",
- .mhandler.cmd_new = qmp_marshal_input_query_alarm_methods,
- },
-
Now Build qemu, run it as explained in the "Testing" section and try our new
command:
projects / mirror_qemu.git / blobdiff