2020-02-24 15:29:49 +01:00
|
|
|
/*
|
|
|
|
* QEMU storage daemon
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003-2008 Fabrice Bellard
|
|
|
|
* Copyright (c) 2019 Kevin Wolf <kwolf@redhat.com>
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "qemu/osdep.h"
|
|
|
|
|
|
|
|
#include <getopt.h>
|
|
|
|
|
|
|
|
#include "block/block.h"
|
2020-02-24 15:29:57 +01:00
|
|
|
#include "block/nbd.h"
|
2020-02-24 15:30:01 +01:00
|
|
|
#include "chardev/char.h"
|
2020-02-24 15:29:49 +01:00
|
|
|
#include "crypto/init.h"
|
2020-02-24 15:30:08 +01:00
|
|
|
#include "monitor/monitor.h"
|
|
|
|
#include "monitor/monitor-internal.h"
|
2020-02-24 15:29:49 +01:00
|
|
|
|
|
|
|
#include "qapi/error.h"
|
2020-02-24 15:29:57 +01:00
|
|
|
#include "qapi/qapi-visit-block-core.h"
|
2020-09-24 17:26:48 +02:00
|
|
|
#include "qapi/qapi-visit-block-export.h"
|
2020-02-24 15:30:08 +01:00
|
|
|
#include "qapi/qapi-visit-control.h"
|
2020-02-24 15:29:56 +01:00
|
|
|
#include "qapi/qmp/qdict.h"
|
2020-02-24 15:30:08 +01:00
|
|
|
#include "qapi/qmp/qstring.h"
|
2020-02-24 15:29:54 +01:00
|
|
|
#include "qapi/qobject-input-visitor.h"
|
|
|
|
|
2022-04-20 15:25:49 +02:00
|
|
|
#include "qemu/help-texts.h"
|
2020-02-24 15:29:49 +01:00
|
|
|
#include "qemu-version.h"
|
2022-05-25 16:41:26 +02:00
|
|
|
#include "qemu/cutils.h"
|
2020-02-24 15:29:49 +01:00
|
|
|
#include "qemu/config-file.h"
|
|
|
|
#include "qemu/error-report.h"
|
2020-02-24 15:29:56 +01:00
|
|
|
#include "qemu/help_option.h"
|
2020-02-24 15:29:49 +01:00
|
|
|
#include "qemu/log.h"
|
|
|
|
#include "qemu/main-loop.h"
|
|
|
|
#include "qemu/module.h"
|
2020-02-24 15:29:56 +01:00
|
|
|
#include "qemu/option.h"
|
|
|
|
#include "qom/object_interfaces.h"
|
2020-02-24 15:29:49 +01:00
|
|
|
|
2020-02-24 15:30:08 +01:00
|
|
|
#include "storage-daemon/qapi/qapi-commands.h"
|
|
|
|
#include "storage-daemon/qapi/qapi-init-commands.h"
|
|
|
|
|
2020-02-24 15:30:00 +01:00
|
|
|
#include "sysemu/runstate.h"
|
2020-02-24 15:29:49 +01:00
|
|
|
#include "trace/control.h"
|
|
|
|
|
2021-03-02 15:27:46 +01:00
|
|
|
static const char *pid_file;
|
2020-02-24 15:30:00 +01:00
|
|
|
static volatile bool exit_requested = false;
|
|
|
|
|
|
|
|
void qemu_system_killed(int signal, pid_t pid)
|
|
|
|
{
|
|
|
|
exit_requested = true;
|
|
|
|
}
|
|
|
|
|
2020-02-24 15:30:08 +01:00
|
|
|
void qmp_quit(Error **errp)
|
|
|
|
{
|
|
|
|
exit_requested = true;
|
|
|
|
}
|
|
|
|
|
2020-02-24 15:29:49 +01:00
|
|
|
static void help(void)
|
|
|
|
{
|
|
|
|
printf(
|
|
|
|
"Usage: %s [options]\n"
|
|
|
|
"QEMU storage daemon\n"
|
|
|
|
"\n"
|
|
|
|
" -h, --help display this help and exit\n"
|
|
|
|
" -T, --trace [[enable=]<pattern>][,events=<file>][,file=<file>]\n"
|
|
|
|
" specify tracing options\n"
|
|
|
|
" -V, --version output version information and exit\n"
|
|
|
|
"\n"
|
2020-02-24 15:29:54 +01:00
|
|
|
" --blockdev [driver=]<driver>[,node-name=<N>][,discard=ignore|unmap]\n"
|
|
|
|
" [,cache.direct=on|off][,cache.no-flush=on|off]\n"
|
|
|
|
" [,read-only=on|off][,auto-read-only=on|off]\n"
|
|
|
|
" [,force-share=on|off][,detect-zeroes=on|off|unmap]\n"
|
|
|
|
" [,driver specific parameters...]\n"
|
|
|
|
" configure a block backend\n"
|
|
|
|
"\n"
|
2020-02-24 15:30:01 +01:00
|
|
|
" --chardev <options> configure a character device backend\n"
|
|
|
|
" (see the qemu(1) man page for possible options)\n"
|
|
|
|
"\n"
|
qsd: Add --daemonize
To implement this, we reuse the existing daemonizing functions from the
system emulator, which mainly do the following:
- Fork off a child process, and set up a pipe between parent and child
- The parent process waits until the child sends a status byte over the
pipe (0 means that the child was set up successfully; anything else
(including errors or EOF) means that the child was not set up
successfully), and then exits with an appropriate exit status
- The child process enters a new session (forking off again), changes
the umask, and will ignore terminal signals from then on
- Once set-up is complete, the child will chdir to /, redirect all
standard I/O streams to /dev/null, and tell the parent that set-up has
been completed successfully
In contrast to qemu-nbd's --fork implementation, during the set up
phase, error messages are not piped through the parent process.
qemu-nbd mainly does this to detect errors, though (while os_daemonize()
has the child explicitly signal success after set up); because we do not
redirect stderr after forking, error messages continue to appear on
whatever the parent's stderr was (until set up is complete).
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220303164814.284974-4-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:13 +01:00
|
|
|
" --daemonize daemonize the process, and have the parent exit\n"
|
|
|
|
" once startup is complete\n"
|
|
|
|
"\n"
|
2020-09-30 15:39:09 +02:00
|
|
|
" --export [type=]nbd,id=<id>,node-name=<node-name>[,name=<export-name>]\n"
|
2020-02-24 15:29:59 +01:00
|
|
|
" [,writable=on|off][,bitmap=<name>]\n"
|
|
|
|
" export the specified block node over NBD\n"
|
|
|
|
" (requires --nbd-server)\n"
|
|
|
|
"\n"
|
2021-08-16 20:04:42 +02:00
|
|
|
#ifdef CONFIG_FUSE
|
2021-02-17 12:58:44 +01:00
|
|
|
" --export [type=]fuse,id=<id>,node-name=<node-name>,mountpoint=<file>\n"
|
2022-01-31 11:31:24 +01:00
|
|
|
" [,growable=on|off][,writable=on|off][,allow-other=on|off|auto]\n"
|
2021-02-17 12:58:44 +01:00
|
|
|
" export the specified block node over FUSE\n"
|
|
|
|
"\n"
|
2021-08-16 20:04:42 +02:00
|
|
|
#endif /* CONFIG_FUSE */
|
qemu-storage-daemon: Add vhost-user-blk help
Add missing vhost-user-blk help:
$ qemu-storage-daemon -h
...
--export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,
addr.type=unix,addr.path=<socket-path>[,writable=on|off]
[,logical-block-size=<block-size>][,num-queues=<num-queues>]
export the specified block node as a
vhosts-user-blk device over UNIX domain socket
--export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,
fd,addr.str=<fd>[,writable=on|off]
[,logical-block-size=<block-size>][,num-queues=<num-queues>]
export the specified block node as a
vhosts-user-blk device over file descriptor
...
Fixes: 90fc91d50b7 ("convert vhost-user-blk server to block export API")
Reported-by: Qing Wang <qinwang@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220107105420.395011-3-f4bug@amsat.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-01-07 11:54:19 +01:00
|
|
|
#ifdef CONFIG_VHOST_USER_BLK_SERVER
|
|
|
|
" --export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,\n"
|
|
|
|
" addr.type=unix,addr.path=<socket-path>[,writable=on|off]\n"
|
|
|
|
" [,logical-block-size=<block-size>][,num-queues=<num-queues>]\n"
|
|
|
|
" export the specified block node as a\n"
|
|
|
|
" vhost-user-blk device over UNIX domain socket\n"
|
|
|
|
" --export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,\n"
|
2022-01-25 16:15:14 +01:00
|
|
|
" addr.type=fd,addr.str=<fd>[,writable=on|off]\n"
|
qemu-storage-daemon: Add vhost-user-blk help
Add missing vhost-user-blk help:
$ qemu-storage-daemon -h
...
--export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,
addr.type=unix,addr.path=<socket-path>[,writable=on|off]
[,logical-block-size=<block-size>][,num-queues=<num-queues>]
export the specified block node as a
vhosts-user-blk device over UNIX domain socket
--export [type=]vhost-user-blk,id=<id>,node-name=<node-name>,
fd,addr.str=<fd>[,writable=on|off]
[,logical-block-size=<block-size>][,num-queues=<num-queues>]
export the specified block node as a
vhosts-user-blk device over file descriptor
...
Fixes: 90fc91d50b7 ("convert vhost-user-blk server to block export API")
Reported-by: Qing Wang <qinwang@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20220107105420.395011-3-f4bug@amsat.org>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-01-07 11:54:19 +01:00
|
|
|
" [,logical-block-size=<block-size>][,num-queues=<num-queues>]\n"
|
|
|
|
" export the specified block node as a\n"
|
|
|
|
" vhost-user-blk device over file descriptor\n"
|
|
|
|
"\n"
|
|
|
|
#endif /* CONFIG_VHOST_USER_BLK_SERVER */
|
2022-05-25 14:19:47 +02:00
|
|
|
#ifdef CONFIG_VDUSE_BLK_EXPORT
|
|
|
|
" --export [type=]vduse-blk,id=<id>,node-name=<node-name>\n"
|
2022-06-14 07:15:32 +02:00
|
|
|
" ,name=<vduse-name>[,writable=on|off]\n"
|
|
|
|
" [,num-queues=<num-queues>][,queue-size=<queue-size>]\n"
|
2022-05-25 14:19:47 +02:00
|
|
|
" [,logical-block-size=<logical-block-size>]\n"
|
2022-06-14 07:15:31 +02:00
|
|
|
" [,serial=<serial-number>]\n"
|
2022-06-14 07:15:32 +02:00
|
|
|
" export the specified block node as a\n"
|
|
|
|
" vduse-blk device\n"
|
2022-05-25 14:19:47 +02:00
|
|
|
"\n"
|
|
|
|
#endif /* CONFIG_VDUSE_BLK_EXPORT */
|
2020-02-24 15:30:08 +01:00
|
|
|
" --monitor [chardev=]name[,mode=control][,pretty[=on|off]]\n"
|
|
|
|
" configure a QMP monitor\n"
|
|
|
|
"\n"
|
2020-02-24 15:29:57 +01:00
|
|
|
" --nbd-server addr.type=inet,addr.host=<host>,addr.port=<port>\n"
|
2020-09-24 17:26:54 +02:00
|
|
|
" [,tls-creds=<id>][,tls-authz=<id>][,max-connections=<n>]\n"
|
2020-02-24 15:29:57 +01:00
|
|
|
" --nbd-server addr.type=unix,addr.path=<path>\n"
|
2020-09-24 17:26:54 +02:00
|
|
|
" [,tls-creds=<id>][,tls-authz=<id>][,max-connections=<n>]\n"
|
2020-02-24 15:29:57 +01:00
|
|
|
" start an NBD server for exporting block nodes\n"
|
|
|
|
"\n"
|
2020-02-24 15:29:56 +01:00
|
|
|
" --object help list object types that can be added\n"
|
|
|
|
" --object <type>,help list properties for the given object type\n"
|
|
|
|
" --object <type>[,<property>=<value>...]\n"
|
|
|
|
" create a new object of type <type>, setting\n"
|
|
|
|
" properties in the order they are specified. Note\n"
|
|
|
|
" that the 'id' property must be set.\n"
|
|
|
|
" See the qemu(1) man page for documentation of the\n"
|
|
|
|
" objects that can be added.\n"
|
|
|
|
"\n"
|
2021-03-02 15:27:46 +01:00
|
|
|
" --pidfile <path> write process ID to a file after startup\n"
|
|
|
|
"\n"
|
2020-02-24 15:29:49 +01:00
|
|
|
QEMU_HELP_BOTTOM "\n",
|
2022-02-21 11:11:47 +01:00
|
|
|
g_get_prgname());
|
2020-02-24 15:29:49 +01:00
|
|
|
}
|
|
|
|
|
2020-02-24 15:29:54 +01:00
|
|
|
enum {
|
|
|
|
OPTION_BLOCKDEV = 256,
|
2020-02-24 15:30:01 +01:00
|
|
|
OPTION_CHARDEV,
|
qsd: Add --daemonize
To implement this, we reuse the existing daemonizing functions from the
system emulator, which mainly do the following:
- Fork off a child process, and set up a pipe between parent and child
- The parent process waits until the child sends a status byte over the
pipe (0 means that the child was set up successfully; anything else
(including errors or EOF) means that the child was not set up
successfully), and then exits with an appropriate exit status
- The child process enters a new session (forking off again), changes
the umask, and will ignore terminal signals from then on
- Once set-up is complete, the child will chdir to /, redirect all
standard I/O streams to /dev/null, and tell the parent that set-up has
been completed successfully
In contrast to qemu-nbd's --fork implementation, during the set up
phase, error messages are not piped through the parent process.
qemu-nbd mainly does this to detect errors, though (while os_daemonize()
has the child explicitly signal success after set up); because we do not
redirect stderr after forking, error messages continue to appear on
whatever the parent's stderr was (until set up is complete).
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220303164814.284974-4-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:13 +01:00
|
|
|
OPTION_DAEMONIZE,
|
2020-02-24 15:29:59 +01:00
|
|
|
OPTION_EXPORT,
|
2020-02-24 15:30:08 +01:00
|
|
|
OPTION_MONITOR,
|
2020-02-24 15:29:57 +01:00
|
|
|
OPTION_NBD_SERVER,
|
2020-02-24 15:29:56 +01:00
|
|
|
OPTION_OBJECT,
|
2021-03-02 15:27:46 +01:00
|
|
|
OPTION_PIDFILE,
|
2020-02-24 15:29:56 +01:00
|
|
|
};
|
|
|
|
|
2020-02-24 15:30:01 +01:00
|
|
|
extern QemuOptsList qemu_chardev_opts;
|
|
|
|
|
2020-02-24 15:30:08 +01:00
|
|
|
static void init_qmp_commands(void)
|
|
|
|
{
|
|
|
|
qmp_init_marshal(&qmp_commands);
|
|
|
|
|
|
|
|
QTAILQ_INIT(&qmp_cap_negotiation_commands);
|
|
|
|
qmp_register_command(&qmp_cap_negotiation_commands, "qmp_capabilities",
|
2021-10-28 12:25:17 +02:00
|
|
|
qmp_marshal_qmp_capabilities,
|
|
|
|
QCO_ALLOW_PRECONFIG, 0);
|
2020-02-24 15:30:08 +01:00
|
|
|
}
|
|
|
|
|
2021-03-01 16:28:44 +01:00
|
|
|
static int getopt_set_loc(int argc, char **argv, const char *optstring,
|
|
|
|
const struct option *longopts)
|
|
|
|
{
|
|
|
|
int c, save_index;
|
|
|
|
|
|
|
|
optarg = NULL;
|
|
|
|
save_index = optind;
|
|
|
|
c = getopt_long(argc, argv, optstring, longopts, NULL);
|
|
|
|
if (optarg) {
|
|
|
|
loc_set_cmdline(argv, save_index, MAX(1, optind - save_index));
|
|
|
|
}
|
|
|
|
return c;
|
|
|
|
}
|
|
|
|
|
qsd: Add pre-init argument parsing pass
In contrast to qemu-nbd (where it is called --fork) and the system
emulator, QSD does not have a --daemonize switch yet. Just like them,
QSD allows setting up block devices and exports on the command line.
When doing so, it is often necessary for whoever invoked the QSD to wait
until these exports are fully set up. A --daemonize switch allows
precisely this, by virtue of the parent process exiting once everything
is set up.
Note that there are alternative ways of waiting for all exports to be
set up, for example:
- Passing the --pidfile option and waiting until the respective file
exists (but I do not know if there is a way of implementing this
without a busy wait loop)
- Set up some network server (e.g. on a Unix socket) and have the QSD
connect to it after all arguments have been processed by appending
corresponding --chardev and --monitor options to the command line,
and then wait until the QSD connects
Having a --daemonize option would make this simpler, though, without
having to rely on additional tools (to set up a network server) or busy
waiting.
Implementing a --daemonize switch means having to fork the QSD process.
Ideally, we should do this as early as possible: All the parent process
has to do is to wait for the child process to signal completion of its
set-up phase, and therefore there is basically no initialization that
needs to be done before the fork. On the other hand, forking after
initialization steps means having to consider how those steps (like
setting up the block layer or QMP) interact with a later fork, which is
often not trivial.
In order to fork this early, we must scan the command line for
--daemonize long before our current process_options() call. Instead of
adding custom new code to do so, just reuse process_options() and give
it a @pre_init_pass argument to distinguish the two passes. I believe
there are some other switches but --daemonize that deserve parsing in
the first pass:
- --help and --version are supposed to only print some text and then
immediately exit (so any initialization we do would be for naught).
This changes behavior, because now "--blockdev inv-drv --help" will
print a help text instead of complaining about the --blockdev
argument.
Note that this is similar in behavior to other tools, though: "--help"
is generally immediately acted upon when finding it in the argument
list, potentially before other arguments (even ones before it) are
acted on. For example, "ls /does-not-exist --help" prints a help text
and does not complain about ENOENT.
- --pidfile does not need initialization, and is already exempted from
the sequential order that process_options() claims to strictly follow
(the PID file is only created after all arguments are processed, not
at the time the --pidfile argument appears), so it makes sense to
include it in the same category as --daemonize.
- Invalid arguments should always be reported as soon as possible. (The
same caveat with --help applies: That means that "--blockdev inv-drv
--inv-arg" will now complain about --inv-arg, not inv-drv.)
This patch does make some references to --daemonize without having
implemented it yet, but that will happen in the next patch.
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20220303164814.284974-3-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:12 +01:00
|
|
|
/**
|
|
|
|
* Process QSD command-line arguments.
|
|
|
|
*
|
|
|
|
* This is done in two passes:
|
|
|
|
*
|
|
|
|
* First (@pre_init_pass is true), we do a pass where all global
|
|
|
|
* arguments pertaining to the QSD process (like --help or --daemonize)
|
|
|
|
* are processed. This pass is done before most of the QEMU-specific
|
|
|
|
* initialization steps (e.g. initializing the block layer or QMP), and
|
|
|
|
* so must only process arguments that are not really QEMU-specific.
|
|
|
|
*
|
|
|
|
* Second (@pre_init_pass is false), we (sequentially) process all
|
|
|
|
* QEMU/QSD-specific arguments. Many of these arguments are effectively
|
|
|
|
* translated to QMP commands (like --blockdev for blockdev-add, or
|
|
|
|
* --export for block-export-add).
|
|
|
|
*/
|
|
|
|
static void process_options(int argc, char *argv[], bool pre_init_pass)
|
2020-02-24 15:29:49 +01:00
|
|
|
{
|
|
|
|
int c;
|
|
|
|
|
|
|
|
static const struct option long_options[] = {
|
2020-02-24 15:29:54 +01:00
|
|
|
{"blockdev", required_argument, NULL, OPTION_BLOCKDEV},
|
2020-02-24 15:30:01 +01:00
|
|
|
{"chardev", required_argument, NULL, OPTION_CHARDEV},
|
qsd: Add --daemonize
To implement this, we reuse the existing daemonizing functions from the
system emulator, which mainly do the following:
- Fork off a child process, and set up a pipe between parent and child
- The parent process waits until the child sends a status byte over the
pipe (0 means that the child was set up successfully; anything else
(including errors or EOF) means that the child was not set up
successfully), and then exits with an appropriate exit status
- The child process enters a new session (forking off again), changes
the umask, and will ignore terminal signals from then on
- Once set-up is complete, the child will chdir to /, redirect all
standard I/O streams to /dev/null, and tell the parent that set-up has
been completed successfully
In contrast to qemu-nbd's --fork implementation, during the set up
phase, error messages are not piped through the parent process.
qemu-nbd mainly does this to detect errors, though (while os_daemonize()
has the child explicitly signal success after set up); because we do not
redirect stderr after forking, error messages continue to appear on
whatever the parent's stderr was (until set up is complete).
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220303164814.284974-4-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:13 +01:00
|
|
|
{"daemonize", no_argument, NULL, OPTION_DAEMONIZE},
|
2020-02-24 15:29:59 +01:00
|
|
|
{"export", required_argument, NULL, OPTION_EXPORT},
|
2020-02-24 15:29:49 +01:00
|
|
|
{"help", no_argument, NULL, 'h'},
|
2020-02-24 15:30:08 +01:00
|
|
|
{"monitor", required_argument, NULL, OPTION_MONITOR},
|
2020-02-24 15:29:57 +01:00
|
|
|
{"nbd-server", required_argument, NULL, OPTION_NBD_SERVER},
|
2020-02-24 15:29:56 +01:00
|
|
|
{"object", required_argument, NULL, OPTION_OBJECT},
|
2021-03-02 15:27:46 +01:00
|
|
|
{"pidfile", required_argument, NULL, OPTION_PIDFILE},
|
2020-02-24 15:29:49 +01:00
|
|
|
{"trace", required_argument, NULL, 'T'},
|
|
|
|
{"version", no_argument, NULL, 'V'},
|
|
|
|
{0, 0, 0, 0}
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
qsd: Add pre-init argument parsing pass
In contrast to qemu-nbd (where it is called --fork) and the system
emulator, QSD does not have a --daemonize switch yet. Just like them,
QSD allows setting up block devices and exports on the command line.
When doing so, it is often necessary for whoever invoked the QSD to wait
until these exports are fully set up. A --daemonize switch allows
precisely this, by virtue of the parent process exiting once everything
is set up.
Note that there are alternative ways of waiting for all exports to be
set up, for example:
- Passing the --pidfile option and waiting until the respective file
exists (but I do not know if there is a way of implementing this
without a busy wait loop)
- Set up some network server (e.g. on a Unix socket) and have the QSD
connect to it after all arguments have been processed by appending
corresponding --chardev and --monitor options to the command line,
and then wait until the QSD connects
Having a --daemonize option would make this simpler, though, without
having to rely on additional tools (to set up a network server) or busy
waiting.
Implementing a --daemonize switch means having to fork the QSD process.
Ideally, we should do this as early as possible: All the parent process
has to do is to wait for the child process to signal completion of its
set-up phase, and therefore there is basically no initialization that
needs to be done before the fork. On the other hand, forking after
initialization steps means having to consider how those steps (like
setting up the block layer or QMP) interact with a later fork, which is
often not trivial.
In order to fork this early, we must scan the command line for
--daemonize long before our current process_options() call. Instead of
adding custom new code to do so, just reuse process_options() and give
it a @pre_init_pass argument to distinguish the two passes. I believe
there are some other switches but --daemonize that deserve parsing in
the first pass:
- --help and --version are supposed to only print some text and then
immediately exit (so any initialization we do would be for naught).
This changes behavior, because now "--blockdev inv-drv --help" will
print a help text instead of complaining about the --blockdev
argument.
Note that this is similar in behavior to other tools, though: "--help"
is generally immediately acted upon when finding it in the argument
list, potentially before other arguments (even ones before it) are
acted on. For example, "ls /does-not-exist --help" prints a help text
and does not complain about ENOENT.
- --pidfile does not need initialization, and is already exempted from
the sequential order that process_options() claims to strictly follow
(the PID file is only created after all arguments are processed, not
at the time the --pidfile argument appears), so it makes sense to
include it in the same category as --daemonize.
- Invalid arguments should always be reported as soon as possible. (The
same caveat with --help applies: That means that "--blockdev inv-drv
--inv-arg" will now complain about --inv-arg, not inv-drv.)
This patch does make some references to --daemonize without having
implemented it yet, but that will happen in the next patch.
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20220303164814.284974-3-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:12 +01:00
|
|
|
* In contrast to the system emulator, QEMU-specific options are processed
|
|
|
|
* in the order they are given on the command lines. This means that things
|
|
|
|
* must be defined first before they can be referenced in another option.
|
2020-02-24 15:29:49 +01:00
|
|
|
*/
|
qsd: Add pre-init argument parsing pass
In contrast to qemu-nbd (where it is called --fork) and the system
emulator, QSD does not have a --daemonize switch yet. Just like them,
QSD allows setting up block devices and exports on the command line.
When doing so, it is often necessary for whoever invoked the QSD to wait
until these exports are fully set up. A --daemonize switch allows
precisely this, by virtue of the parent process exiting once everything
is set up.
Note that there are alternative ways of waiting for all exports to be
set up, for example:
- Passing the --pidfile option and waiting until the respective file
exists (but I do not know if there is a way of implementing this
without a busy wait loop)
- Set up some network server (e.g. on a Unix socket) and have the QSD
connect to it after all arguments have been processed by appending
corresponding --chardev and --monitor options to the command line,
and then wait until the QSD connects
Having a --daemonize option would make this simpler, though, without
having to rely on additional tools (to set up a network server) or busy
waiting.
Implementing a --daemonize switch means having to fork the QSD process.
Ideally, we should do this as early as possible: All the parent process
has to do is to wait for the child process to signal completion of its
set-up phase, and therefore there is basically no initialization that
needs to be done before the fork. On the other hand, forking after
initialization steps means having to consider how those steps (like
setting up the block layer or QMP) interact with a later fork, which is
often not trivial.
In order to fork this early, we must scan the command line for
--daemonize long before our current process_options() call. Instead of
adding custom new code to do so, just reuse process_options() and give
it a @pre_init_pass argument to distinguish the two passes. I believe
there are some other switches but --daemonize that deserve parsing in
the first pass:
- --help and --version are supposed to only print some text and then
immediately exit (so any initialization we do would be for naught).
This changes behavior, because now "--blockdev inv-drv --help" will
print a help text instead of complaining about the --blockdev
argument.
Note that this is similar in behavior to other tools, though: "--help"
is generally immediately acted upon when finding it in the argument
list, potentially before other arguments (even ones before it) are
acted on. For example, "ls /does-not-exist --help" prints a help text
and does not complain about ENOENT.
- --pidfile does not need initialization, and is already exempted from
the sequential order that process_options() claims to strictly follow
(the PID file is only created after all arguments are processed, not
at the time the --pidfile argument appears), so it makes sense to
include it in the same category as --daemonize.
- Invalid arguments should always be reported as soon as possible. (The
same caveat with --help applies: That means that "--blockdev inv-drv
--inv-arg" will now complain about --inv-arg, not inv-drv.)
This patch does make some references to --daemonize without having
implemented it yet, but that will happen in the next patch.
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20220303164814.284974-3-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:12 +01:00
|
|
|
optind = 1;
|
2021-03-01 16:28:44 +01:00
|
|
|
while ((c = getopt_set_loc(argc, argv, "-hT:V", long_options)) != -1) {
|
qsd: Add pre-init argument parsing pass
In contrast to qemu-nbd (where it is called --fork) and the system
emulator, QSD does not have a --daemonize switch yet. Just like them,
QSD allows setting up block devices and exports on the command line.
When doing so, it is often necessary for whoever invoked the QSD to wait
until these exports are fully set up. A --daemonize switch allows
precisely this, by virtue of the parent process exiting once everything
is set up.
Note that there are alternative ways of waiting for all exports to be
set up, for example:
- Passing the --pidfile option and waiting until the respective file
exists (but I do not know if there is a way of implementing this
without a busy wait loop)
- Set up some network server (e.g. on a Unix socket) and have the QSD
connect to it after all arguments have been processed by appending
corresponding --chardev and --monitor options to the command line,
and then wait until the QSD connects
Having a --daemonize option would make this simpler, though, without
having to rely on additional tools (to set up a network server) or busy
waiting.
Implementing a --daemonize switch means having to fork the QSD process.
Ideally, we should do this as early as possible: All the parent process
has to do is to wait for the child process to signal completion of its
set-up phase, and therefore there is basically no initialization that
needs to be done before the fork. On the other hand, forking after
initialization steps means having to consider how those steps (like
setting up the block layer or QMP) interact with a later fork, which is
often not trivial.
In order to fork this early, we must scan the command line for
--daemonize long before our current process_options() call. Instead of
adding custom new code to do so, just reuse process_options() and give
it a @pre_init_pass argument to distinguish the two passes. I believe
there are some other switches but --daemonize that deserve parsing in
the first pass:
- --help and --version are supposed to only print some text and then
immediately exit (so any initialization we do would be for naught).
This changes behavior, because now "--blockdev inv-drv --help" will
print a help text instead of complaining about the --blockdev
argument.
Note that this is similar in behavior to other tools, though: "--help"
is generally immediately acted upon when finding it in the argument
list, potentially before other arguments (even ones before it) are
acted on. For example, "ls /does-not-exist --help" prints a help text
and does not complain about ENOENT.
- --pidfile does not need initialization, and is already exempted from
the sequential order that process_options() claims to strictly follow
(the PID file is only created after all arguments are processed, not
at the time the --pidfile argument appears), so it makes sense to
include it in the same category as --daemonize.
- Invalid arguments should always be reported as soon as possible. (The
same caveat with --help applies: That means that "--blockdev inv-drv
--inv-arg" will now complain about --inv-arg, not inv-drv.)
This patch does make some references to --daemonize without having
implemented it yet, but that will happen in the next patch.
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20220303164814.284974-3-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:12 +01:00
|
|
|
bool handle_option_pre_init;
|
|
|
|
|
|
|
|
/* Should this argument be processed in the pre-init pass? */
|
|
|
|
handle_option_pre_init =
|
|
|
|
c == '?' ||
|
|
|
|
c == 'h' ||
|
|
|
|
c == 'V' ||
|
qsd: Add --daemonize
To implement this, we reuse the existing daemonizing functions from the
system emulator, which mainly do the following:
- Fork off a child process, and set up a pipe between parent and child
- The parent process waits until the child sends a status byte over the
pipe (0 means that the child was set up successfully; anything else
(including errors or EOF) means that the child was not set up
successfully), and then exits with an appropriate exit status
- The child process enters a new session (forking off again), changes
the umask, and will ignore terminal signals from then on
- Once set-up is complete, the child will chdir to /, redirect all
standard I/O streams to /dev/null, and tell the parent that set-up has
been completed successfully
In contrast to qemu-nbd's --fork implementation, during the set up
phase, error messages are not piped through the parent process.
qemu-nbd mainly does this to detect errors, though (while os_daemonize()
has the child explicitly signal success after set up); because we do not
redirect stderr after forking, error messages continue to appear on
whatever the parent's stderr was (until set up is complete).
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220303164814.284974-4-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:13 +01:00
|
|
|
c == OPTION_DAEMONIZE ||
|
qsd: Add pre-init argument parsing pass
In contrast to qemu-nbd (where it is called --fork) and the system
emulator, QSD does not have a --daemonize switch yet. Just like them,
QSD allows setting up block devices and exports on the command line.
When doing so, it is often necessary for whoever invoked the QSD to wait
until these exports are fully set up. A --daemonize switch allows
precisely this, by virtue of the parent process exiting once everything
is set up.
Note that there are alternative ways of waiting for all exports to be
set up, for example:
- Passing the --pidfile option and waiting until the respective file
exists (but I do not know if there is a way of implementing this
without a busy wait loop)
- Set up some network server (e.g. on a Unix socket) and have the QSD
connect to it after all arguments have been processed by appending
corresponding --chardev and --monitor options to the command line,
and then wait until the QSD connects
Having a --daemonize option would make this simpler, though, without
having to rely on additional tools (to set up a network server) or busy
waiting.
Implementing a --daemonize switch means having to fork the QSD process.
Ideally, we should do this as early as possible: All the parent process
has to do is to wait for the child process to signal completion of its
set-up phase, and therefore there is basically no initialization that
needs to be done before the fork. On the other hand, forking after
initialization steps means having to consider how those steps (like
setting up the block layer or QMP) interact with a later fork, which is
often not trivial.
In order to fork this early, we must scan the command line for
--daemonize long before our current process_options() call. Instead of
adding custom new code to do so, just reuse process_options() and give
it a @pre_init_pass argument to distinguish the two passes. I believe
there are some other switches but --daemonize that deserve parsing in
the first pass:
- --help and --version are supposed to only print some text and then
immediately exit (so any initialization we do would be for naught).
This changes behavior, because now "--blockdev inv-drv --help" will
print a help text instead of complaining about the --blockdev
argument.
Note that this is similar in behavior to other tools, though: "--help"
is generally immediately acted upon when finding it in the argument
list, potentially before other arguments (even ones before it) are
acted on. For example, "ls /does-not-exist --help" prints a help text
and does not complain about ENOENT.
- --pidfile does not need initialization, and is already exempted from
the sequential order that process_options() claims to strictly follow
(the PID file is only created after all arguments are processed, not
at the time the --pidfile argument appears), so it makes sense to
include it in the same category as --daemonize.
- Invalid arguments should always be reported as soon as possible. (The
same caveat with --help applies: That means that "--blockdev inv-drv
--inv-arg" will now complain about --inv-arg, not inv-drv.)
This patch does make some references to --daemonize without having
implemented it yet, but that will happen in the next patch.
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20220303164814.284974-3-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:12 +01:00
|
|
|
c == OPTION_PIDFILE;
|
|
|
|
|
|
|
|
/* Process every option only in its respective pass */
|
|
|
|
if (pre_init_pass != handle_option_pre_init) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2020-02-24 15:29:49 +01:00
|
|
|
switch (c) {
|
|
|
|
case '?':
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
case 'h':
|
|
|
|
help();
|
|
|
|
exit(EXIT_SUCCESS);
|
|
|
|
case 'T':
|
2020-11-02 12:58:41 +01:00
|
|
|
trace_opt_parse(optarg);
|
|
|
|
trace_init_file();
|
|
|
|
break;
|
2020-02-24 15:29:49 +01:00
|
|
|
case 'V':
|
|
|
|
printf("qemu-storage-daemon version "
|
|
|
|
QEMU_FULL_VERSION "\n" QEMU_COPYRIGHT "\n");
|
|
|
|
exit(EXIT_SUCCESS);
|
2020-02-24 15:29:54 +01:00
|
|
|
case OPTION_BLOCKDEV:
|
|
|
|
{
|
|
|
|
Visitor *v;
|
|
|
|
BlockdevOptions *options;
|
|
|
|
|
|
|
|
v = qobject_input_visitor_new_str(optarg, "driver",
|
|
|
|
&error_fatal);
|
|
|
|
|
|
|
|
visit_type_BlockdevOptions(v, NULL, &options, &error_fatal);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
qmp_blockdev_add(options, &error_fatal);
|
|
|
|
qapi_free_BlockdevOptions(options);
|
|
|
|
break;
|
|
|
|
}
|
2020-02-24 15:30:01 +01:00
|
|
|
case OPTION_CHARDEV:
|
|
|
|
{
|
|
|
|
/* TODO This interface is not stable until we QAPIfy it */
|
|
|
|
QemuOpts *opts = qemu_opts_parse_noisily(&qemu_chardev_opts,
|
|
|
|
optarg, true);
|
|
|
|
if (opts == NULL) {
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!qemu_chr_new_from_opts(opts, NULL, &error_fatal)) {
|
|
|
|
/* No error, but NULL returned means help was printed */
|
|
|
|
exit(EXIT_SUCCESS);
|
|
|
|
}
|
|
|
|
qemu_opts_del(opts);
|
|
|
|
break;
|
|
|
|
}
|
qsd: Add --daemonize
To implement this, we reuse the existing daemonizing functions from the
system emulator, which mainly do the following:
- Fork off a child process, and set up a pipe between parent and child
- The parent process waits until the child sends a status byte over the
pipe (0 means that the child was set up successfully; anything else
(including errors or EOF) means that the child was not set up
successfully), and then exits with an appropriate exit status
- The child process enters a new session (forking off again), changes
the umask, and will ignore terminal signals from then on
- Once set-up is complete, the child will chdir to /, redirect all
standard I/O streams to /dev/null, and tell the parent that set-up has
been completed successfully
In contrast to qemu-nbd's --fork implementation, during the set up
phase, error messages are not piped through the parent process.
qemu-nbd mainly does this to detect errors, though (while os_daemonize()
has the child explicitly signal success after set up); because we do not
redirect stderr after forking, error messages continue to appear on
whatever the parent's stderr was (until set up is complete).
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220303164814.284974-4-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:13 +01:00
|
|
|
case OPTION_DAEMONIZE:
|
|
|
|
if (os_set_daemonize(true) < 0) {
|
2022-06-09 14:28:52 +02:00
|
|
|
/*
|
|
|
|
* --daemonize is parsed before monitor_init_globals_core(), so
|
|
|
|
* error_report() does not work yet
|
|
|
|
*/
|
|
|
|
fprintf(stderr, "--daemonize not supported in this build\n");
|
qsd: Add --daemonize
To implement this, we reuse the existing daemonizing functions from the
system emulator, which mainly do the following:
- Fork off a child process, and set up a pipe between parent and child
- The parent process waits until the child sends a status byte over the
pipe (0 means that the child was set up successfully; anything else
(including errors or EOF) means that the child was not set up
successfully), and then exits with an appropriate exit status
- The child process enters a new session (forking off again), changes
the umask, and will ignore terminal signals from then on
- Once set-up is complete, the child will chdir to /, redirect all
standard I/O streams to /dev/null, and tell the parent that set-up has
been completed successfully
In contrast to qemu-nbd's --fork implementation, during the set up
phase, error messages are not piped through the parent process.
qemu-nbd mainly does this to detect errors, though (while os_daemonize()
has the child explicitly signal success after set up); because we do not
redirect stderr after forking, error messages continue to appear on
whatever the parent's stderr was (until set up is complete).
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220303164814.284974-4-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:13 +01:00
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
break;
|
2020-02-24 15:29:59 +01:00
|
|
|
case OPTION_EXPORT:
|
|
|
|
{
|
|
|
|
Visitor *v;
|
2020-09-24 17:26:49 +02:00
|
|
|
BlockExportOptions *export;
|
2020-02-24 15:29:59 +01:00
|
|
|
|
|
|
|
v = qobject_input_visitor_new_str(optarg, "type", &error_fatal);
|
2020-09-24 17:26:49 +02:00
|
|
|
visit_type_BlockExportOptions(v, NULL, &export, &error_fatal);
|
2020-02-24 15:29:59 +01:00
|
|
|
visit_free(v);
|
|
|
|
|
2020-09-24 17:26:51 +02:00
|
|
|
qmp_block_export_add(export, &error_fatal);
|
2020-09-24 17:26:49 +02:00
|
|
|
qapi_free_BlockExportOptions(export);
|
2020-02-24 15:29:59 +01:00
|
|
|
break;
|
|
|
|
}
|
2020-02-24 15:30:08 +01:00
|
|
|
case OPTION_MONITOR:
|
|
|
|
{
|
|
|
|
Visitor *v;
|
|
|
|
MonitorOptions *monitor;
|
|
|
|
|
|
|
|
v = qobject_input_visitor_new_str(optarg, "chardev",
|
|
|
|
&error_fatal);
|
|
|
|
visit_type_MonitorOptions(v, NULL, &monitor, &error_fatal);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* TODO Catch duplicate monitor IDs */
|
|
|
|
monitor_init(monitor, false, &error_fatal);
|
|
|
|
qapi_free_MonitorOptions(monitor);
|
|
|
|
break;
|
|
|
|
}
|
2020-02-24 15:29:57 +01:00
|
|
|
case OPTION_NBD_SERVER:
|
|
|
|
{
|
|
|
|
Visitor *v;
|
|
|
|
NbdServerOptions *options;
|
|
|
|
|
|
|
|
v = qobject_input_visitor_new_str(optarg, NULL, &error_fatal);
|
|
|
|
visit_type_NbdServerOptions(v, NULL, &options, &error_fatal);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
nbd_server_start_options(options, &error_fatal);
|
|
|
|
qapi_free_NbdServerOptions(options);
|
|
|
|
break;
|
|
|
|
}
|
2020-02-24 15:29:56 +01:00
|
|
|
case OPTION_OBJECT:
|
2021-02-17 12:06:20 +01:00
|
|
|
user_creatable_process_cmdline(optarg);
|
|
|
|
break;
|
2021-03-02 15:27:46 +01:00
|
|
|
case OPTION_PIDFILE:
|
|
|
|
pid_file = optarg;
|
|
|
|
break;
|
2021-03-01 16:28:43 +01:00
|
|
|
case 1:
|
2021-03-01 16:28:44 +01:00
|
|
|
error_report("Unexpected argument");
|
2021-03-01 16:28:43 +01:00
|
|
|
exit(EXIT_FAILURE);
|
2020-02-24 15:29:49 +01:00
|
|
|
default:
|
|
|
|
g_assert_not_reached();
|
|
|
|
}
|
|
|
|
}
|
2021-03-01 16:28:44 +01:00
|
|
|
loc_set_none();
|
2020-02-24 15:29:49 +01:00
|
|
|
}
|
|
|
|
|
2021-03-02 15:27:46 +01:00
|
|
|
static void pid_file_cleanup(void)
|
|
|
|
{
|
|
|
|
unlink(pid_file);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pid_file_init(void)
|
|
|
|
{
|
|
|
|
Error *err = NULL;
|
|
|
|
|
|
|
|
if (!pid_file) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!qemu_write_pidfile(pid_file, &err)) {
|
|
|
|
error_reportf_err(err, "cannot create PID file: ");
|
|
|
|
exit(EXIT_FAILURE);
|
|
|
|
}
|
|
|
|
|
|
|
|
atexit(pid_file_cleanup);
|
|
|
|
}
|
|
|
|
|
2020-02-24 15:29:49 +01:00
|
|
|
int main(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_POSIX
|
|
|
|
signal(SIGPIPE, SIG_IGN);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
error_init(argv[0]);
|
|
|
|
qemu_init_exec_dir(argv[0]);
|
2020-02-24 15:30:00 +01:00
|
|
|
os_setup_signal_handling();
|
2020-02-24 15:29:49 +01:00
|
|
|
|
qsd: Add pre-init argument parsing pass
In contrast to qemu-nbd (where it is called --fork) and the system
emulator, QSD does not have a --daemonize switch yet. Just like them,
QSD allows setting up block devices and exports on the command line.
When doing so, it is often necessary for whoever invoked the QSD to wait
until these exports are fully set up. A --daemonize switch allows
precisely this, by virtue of the parent process exiting once everything
is set up.
Note that there are alternative ways of waiting for all exports to be
set up, for example:
- Passing the --pidfile option and waiting until the respective file
exists (but I do not know if there is a way of implementing this
without a busy wait loop)
- Set up some network server (e.g. on a Unix socket) and have the QSD
connect to it after all arguments have been processed by appending
corresponding --chardev and --monitor options to the command line,
and then wait until the QSD connects
Having a --daemonize option would make this simpler, though, without
having to rely on additional tools (to set up a network server) or busy
waiting.
Implementing a --daemonize switch means having to fork the QSD process.
Ideally, we should do this as early as possible: All the parent process
has to do is to wait for the child process to signal completion of its
set-up phase, and therefore there is basically no initialization that
needs to be done before the fork. On the other hand, forking after
initialization steps means having to consider how those steps (like
setting up the block layer or QMP) interact with a later fork, which is
often not trivial.
In order to fork this early, we must scan the command line for
--daemonize long before our current process_options() call. Instead of
adding custom new code to do so, just reuse process_options() and give
it a @pre_init_pass argument to distinguish the two passes. I believe
there are some other switches but --daemonize that deserve parsing in
the first pass:
- --help and --version are supposed to only print some text and then
immediately exit (so any initialization we do would be for naught).
This changes behavior, because now "--blockdev inv-drv --help" will
print a help text instead of complaining about the --blockdev
argument.
Note that this is similar in behavior to other tools, though: "--help"
is generally immediately acted upon when finding it in the argument
list, potentially before other arguments (even ones before it) are
acted on. For example, "ls /does-not-exist --help" prints a help text
and does not complain about ENOENT.
- --pidfile does not need initialization, and is already exempted from
the sequential order that process_options() claims to strictly follow
(the PID file is only created after all arguments are processed, not
at the time the --pidfile argument appears), so it makes sense to
include it in the same category as --daemonize.
- Invalid arguments should always be reported as soon as possible. (The
same caveat with --help applies: That means that "--blockdev inv-drv
--inv-arg" will now complain about --inv-arg, not inv-drv.)
This patch does make some references to --daemonize without having
implemented it yet, but that will happen in the next patch.
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20220303164814.284974-3-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:12 +01:00
|
|
|
process_options(argc, argv, true);
|
|
|
|
|
qsd: Add --daemonize
To implement this, we reuse the existing daemonizing functions from the
system emulator, which mainly do the following:
- Fork off a child process, and set up a pipe between parent and child
- The parent process waits until the child sends a status byte over the
pipe (0 means that the child was set up successfully; anything else
(including errors or EOF) means that the child was not set up
successfully), and then exits with an appropriate exit status
- The child process enters a new session (forking off again), changes
the umask, and will ignore terminal signals from then on
- Once set-up is complete, the child will chdir to /, redirect all
standard I/O streams to /dev/null, and tell the parent that set-up has
been completed successfully
In contrast to qemu-nbd's --fork implementation, during the set up
phase, error messages are not piped through the parent process.
qemu-nbd mainly does this to detect errors, though (while os_daemonize()
has the child explicitly signal success after set up); because we do not
redirect stderr after forking, error messages continue to appear on
whatever the parent's stderr was (until set up is complete).
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220303164814.284974-4-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:13 +01:00
|
|
|
os_daemonize();
|
|
|
|
|
2020-02-24 15:29:49 +01:00
|
|
|
module_call_init(MODULE_INIT_QOM);
|
|
|
|
module_call_init(MODULE_INIT_TRACE);
|
|
|
|
qemu_add_opts(&qemu_trace_opts);
|
|
|
|
qcrypto_init(&error_fatal);
|
|
|
|
bdrv_init();
|
2020-02-24 15:30:08 +01:00
|
|
|
monitor_init_globals_core();
|
|
|
|
init_qmp_commands();
|
2020-02-24 15:29:49 +01:00
|
|
|
|
|
|
|
if (!trace_init_backends()) {
|
|
|
|
return EXIT_FAILURE;
|
|
|
|
}
|
2022-04-17 20:29:44 +02:00
|
|
|
qemu_set_log(LOG_TRACE, &error_fatal);
|
2020-02-24 15:29:49 +01:00
|
|
|
|
|
|
|
qemu_init_main_loop(&error_fatal);
|
qsd: Add pre-init argument parsing pass
In contrast to qemu-nbd (where it is called --fork) and the system
emulator, QSD does not have a --daemonize switch yet. Just like them,
QSD allows setting up block devices and exports on the command line.
When doing so, it is often necessary for whoever invoked the QSD to wait
until these exports are fully set up. A --daemonize switch allows
precisely this, by virtue of the parent process exiting once everything
is set up.
Note that there are alternative ways of waiting for all exports to be
set up, for example:
- Passing the --pidfile option and waiting until the respective file
exists (but I do not know if there is a way of implementing this
without a busy wait loop)
- Set up some network server (e.g. on a Unix socket) and have the QSD
connect to it after all arguments have been processed by appending
corresponding --chardev and --monitor options to the command line,
and then wait until the QSD connects
Having a --daemonize option would make this simpler, though, without
having to rely on additional tools (to set up a network server) or busy
waiting.
Implementing a --daemonize switch means having to fork the QSD process.
Ideally, we should do this as early as possible: All the parent process
has to do is to wait for the child process to signal completion of its
set-up phase, and therefore there is basically no initialization that
needs to be done before the fork. On the other hand, forking after
initialization steps means having to consider how those steps (like
setting up the block layer or QMP) interact with a later fork, which is
often not trivial.
In order to fork this early, we must scan the command line for
--daemonize long before our current process_options() call. Instead of
adding custom new code to do so, just reuse process_options() and give
it a @pre_init_pass argument to distinguish the two passes. I believe
there are some other switches but --daemonize that deserve parsing in
the first pass:
- --help and --version are supposed to only print some text and then
immediately exit (so any initialization we do would be for naught).
This changes behavior, because now "--blockdev inv-drv --help" will
print a help text instead of complaining about the --blockdev
argument.
Note that this is similar in behavior to other tools, though: "--help"
is generally immediately acted upon when finding it in the argument
list, potentially before other arguments (even ones before it) are
acted on. For example, "ls /does-not-exist --help" prints a help text
and does not complain about ENOENT.
- --pidfile does not need initialization, and is already exempted from
the sequential order that process_options() claims to strictly follow
(the PID file is only created after all arguments are processed, not
at the time the --pidfile argument appears), so it makes sense to
include it in the same category as --daemonize.
- Invalid arguments should always be reported as soon as possible. (The
same caveat with --help applies: That means that "--blockdev inv-drv
--inv-arg" will now complain about --inv-arg, not inv-drv.)
This patch does make some references to --daemonize without having
implemented it yet, but that will happen in the next patch.
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20220303164814.284974-3-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:12 +01:00
|
|
|
process_options(argc, argv, false);
|
2020-02-24 15:29:49 +01:00
|
|
|
|
2021-03-02 15:27:46 +01:00
|
|
|
/*
|
|
|
|
* Write the pid file after creating chardevs, exports, and NBD servers but
|
|
|
|
* before accepting connections. This ordering is documented. Do not change
|
|
|
|
* it.
|
|
|
|
*/
|
|
|
|
pid_file_init();
|
qsd: Add --daemonize
To implement this, we reuse the existing daemonizing functions from the
system emulator, which mainly do the following:
- Fork off a child process, and set up a pipe between parent and child
- The parent process waits until the child sends a status byte over the
pipe (0 means that the child was set up successfully; anything else
(including errors or EOF) means that the child was not set up
successfully), and then exits with an appropriate exit status
- The child process enters a new session (forking off again), changes
the umask, and will ignore terminal signals from then on
- Once set-up is complete, the child will chdir to /, redirect all
standard I/O streams to /dev/null, and tell the parent that set-up has
been completed successfully
In contrast to qemu-nbd's --fork implementation, during the set up
phase, error messages are not piped through the parent process.
qemu-nbd mainly does this to detect errors, though (while os_daemonize()
has the child explicitly signal success after set up); because we do not
redirect stderr after forking, error messages continue to appear on
whatever the parent's stderr was (until set up is complete).
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20220303164814.284974-4-hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2022-03-03 17:48:13 +01:00
|
|
|
os_setup_post();
|
2021-03-02 15:27:46 +01:00
|
|
|
|
2020-02-24 15:30:00 +01:00
|
|
|
while (!exit_requested) {
|
|
|
|
main_loop_wait(false);
|
|
|
|
}
|
|
|
|
|
2021-02-01 13:50:32 +01:00
|
|
|
blk_exp_close_all();
|
2020-10-27 20:05:56 +01:00
|
|
|
bdrv_drain_all_begin();
|
2021-03-09 13:18:14 +01:00
|
|
|
job_cancel_sync_all();
|
2020-10-27 20:05:56 +01:00
|
|
|
bdrv_close_all();
|
|
|
|
|
2020-06-19 12:11:32 +02:00
|
|
|
monitor_cleanup();
|
|
|
|
qemu_chr_cleanup();
|
|
|
|
user_creatable_cleanup();
|
|
|
|
|
2020-02-24 15:29:49 +01:00
|
|
|
return EXIT_SUCCESS;
|
|
|
|
}
|