Hanna Reitz <hre...@redhat.com> writes: > We want to add a --daemonize argument to QSD's command line.
Why? > This will > require forking the process before we do any complex initialization > steps, like setting up the block layer or QMP. Therefore, we must scan > the command line for it long before our current process_options() call. Can you explain in a bit more detail why early forking is required? I have a strong dislike for parsing more than once... > 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.) > > Note that we could decide to check only for --daemonize in the first > pass, and defer --help, --version, and checking for invalid arguments to > the second one, thus largely keeping our current behavior. However, > this would break "--help --daemonize": The child would print the help > text to stdout, which is redirected to /dev/null, and so the text would > disappear. We would need to have the text be printed to stderr instead, > and this would then make the parent process exit with EXIT_FAILURE, > which is probably not what we want for --help. > > 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 <hre...@redhat.com>
