Add a documentation comment for qemu_get_thread_id(): since this is rather host-OS-specific it's useful if people writing the implementation and people thinking of using the function know what the purpose and limitations are.
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> --- Based on conversation with Dan on IRC, and prompted by the recent patch to add OpenBSD support. Q: should we document exactly what the thread-id value is for each host platform in the QMP documentation ? Somebody writing a management layer app should ideally not have to grovel through the application to figure out what they should do with the integer value they get back from query-cpus... include/qemu/osdep.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h index 4841b5c6b5f..8279f72e5ed 100644 --- a/include/qemu/osdep.h +++ b/include/qemu/osdep.h @@ -515,6 +515,20 @@ bool qemu_has_ofd_lock(void); bool qemu_write_pidfile(const char *pidfile, Error **errp); +/** + * qemu_get_thread_id: Return OS-specific ID of current thread + * + * This function returns an OS-specific identifier of the + * current thread. This will be used for the "thread-id" field in + * the response to the QMP query-cpus and query-iothreads commands. + * The intention is that a VM management layer application can then + * use it to tie specific QEMU vCPU and IO threads to specific host + * CPUs using whatever the host OS's CPU affinity setting API is. + * New implementations of this function for new host OSes should + * return the most sensible integer ID that works for that purpose. + * + * This function should not be used for anything else inside QEMU. + */ int qemu_get_thread_id(void); #ifndef CONFIG_IOVEC -- 2.20.1
