[v2] stop using stdio for monitor/serial/etc with -daemonize

Message ID 508BDD8D.60402@msgid.tls.msk.ru
State New
Headers show

Commit Message

Michael Tokarev Oct. 27, 2012, 1:11 p.m.
On 27.10.2012 16:55, Michael Tokarev wrote:
> On 27.10.2012 16:48, Blue Swirl wrote:
> []
>>> I'd rather have -nographic work with -daemonize, since the
>>> alternative - shown in the patch comment - is rather long and
>>> it is easy to forget to "nullify" some option, while -nographic
>>> can do that easy and it is convinient, but if people dislikes
>>> such natural and easy-for-the-user solutions, I wont insist.
>> Instead of checking just for -nographic or -curses, can we forbid use
>> of any stdio chardev?
> I think that'll be quite a bit more difficult.  Sure, say,
>   -serial stdio -daemonize
> now has the same problem as original
>   -nographic -daemonize.
> It is just now after you mentioned it I realized this omission.
> And it is exactly the same thing actually - we initialize
> stdio for the serial port, in both cases, and it switches
> the tty to raw mode.
> So this patch is insufficient indeed, we still have the
> same issue, and once -nographic -daemonize is disallowed,
> we've much better chances to hit this issue using -serial.
> Oh well.
> Hmm.  Maybe init stdio chardev for something "else" in case
> of -nographic?

This, together with my previous patch, appears to work fine:

(there's no need to add this to windows version, since
we don't daemonize on windows).




--- a/qemu-char.c
+++ b/qemu-char.c
@@ -772,6 +772,10 @@  static CharDriverState *qemu_chr_open_stdio(QemuOpts *opts)
     if (stdio_nb_clients >= STDIO_MAX_CLIENTS) {
         return NULL;
+    if (is_daemonized()) {
+        error_report("cannot use stdio with -daemonize");
+        return NULL;
+    }
     if (stdio_nb_clients == 0) {
         old_fd0_flags = fcntl(0, F_GETFL);
         tcgetattr (0, &oldtty);