On 15.01.2012 20:17, Paolo Bonzini wrote: > On 01/15/2012 01:59 PM, Michael Tokarev wrote: >> On 15.01.2012 14:51, Paolo Bonzini wrote: >>> On 01/14/2012 10:26 AM, Michael Tokarev wrote: >>>> After looking at the yesterdays issue with non-absolute >>>> paths for qemu-nbd arguments and daemon(3), I've a >>>> question. >>>> >>>> Why qemu-nbd daemonizes, and does that only when device >>>> argument is given (dropping -v/verbose case for now)? >>>> >>>> This raises two questions: >>>> >>>> - shouldn't it do the same daemonizing in case of usual >>>> tcp export? >>> >>> Perhaps yes, but in that case you cannot use "qemu-nbd -d" to >>> kill the daemonized process. >> >> Sorry? qemu-nbd -d will connect to the socket the daemonized >> daemon is listening on, the same way as it is done now -- >> nothing really changes there. > > No, "qemu-nbd -d" will connect to the /dev/nbdX device and tell the kernel to > disconnect. This will terminate the daemon (as long as you didn't use > --persistent, at least).
Whatever. In any case qemu-nbd is able to terminate currently running daemon, nothing changes with addition daemonizing here or without - that was my point. >>> Also, one of the best things of systemd is that it handles >>> daemonization on its own, so nowadays it is better not to >>> have process send themselves into background by default. >> >> First, not all the world is systemd. Second, my question was >> merely about consistency -- -c does daemonizing currently and >> there's no way to stop it from doing so > > --verbose is a counterintuitive way not to daemonize, but it works. I know it works (with additional bonus - it shows extra messages). It wasn't my question. >> The primary question was why -c daemonizes unconditionally. > > I don't know. But I don't think daemonizing is really a feature, just > something historical that we have to deal with. Aha. So can't it just go away, or be controlled by another option, not related to -c ? I think it should be good. >> qemu-nbd was runnable on win32 before, so historically it >> was exactly the opposite. I asked you because you mentioned >> it is linux-only for the first time, but indeed, at that >> time it wasn't compilable on win32 already. > > Fixing it would be good indeed. We can use qemu-thread for that for example. > But it looks like the third commit ever to qemu-nbd.c already made it > non-Linux-only. I don't think there ever was a release that supported > qemu-nbd on Win32, right? It is kinda trivial to fix this. But this task becomes completely unrealistic if that will involve another discussion like we currently have. Thanks, /mjt
