Early fatal tapdisk failures are rare but presently go unnoticed. The
less improbable pathologic example case covered here is an AIO init
failure due to resource exhaustion.
At the very least, we would (a) start tapdisk1 synchronously and test
for errors or (b) defer post-daemonization to somewhere after PID_MSG.
Synchronous starts recently becoming more popular -- we used to
daemonize from the first instruction -- sheds light on a more general
issue: tapdisk1 shouldn't detach from blttapctrl at all.
Ergo:
- Eliminate daemon()ization from tapdisk1.
- Leaves detaching as a (hopefully unpopular) option, in case
something is ever found to disagree.
- Makes blktapctrl reap children.
- Assocites child exists with respective tapdisk-channels.
At this point, even doing the right thing (tm) and suspending guests
in face of crashed tapdisks becomes an option, but this takes an
additional patch or two on the agent.