Adding kvm_subprocess

The following patches replace the run_bg() function and the kvm_spawn class
with kvm_subprocess. The new module is intended to solve a problem with
run_bg() (which loses track of the child process when the parent process
exits) and allows for more flexibility in handling SSH/Telnet sessions (allows
reusing sessions started in previous tests).

kvm_subprocess defines a class 'kvm_spawn' and two functions: run_bg() and
run_fg(). Its main job is to run a process in the background and allow the
user to control it interactively and/or monitor its output on the fly. Its most
important feature in the context of KVM tests is that it allows to control
child processes left behind by processes that no longer exist. This means that
if QEMU is started by the 'boot' test, its output will be logged in the
following 'reboot' test as well.

See kvm_spawn's docstring for more details.

[lmr, 2009-06-18 08:55:41]

Hi Michael, this is my first review of your patch series. The module
kvm_subprocess looks pretty good and carefully written, I made some minor
comments (some of them are more of general wonderings).

After reviewing this, I began to think seriously about replacing pexpect by this
library.

Thank you very much for your work on this,

http://codereview.appspot.com/79042/diff/1/4
File client/tests/kvm/kvm_subprocess.py (right):

http://codereview.appspot.com/79042/diff/1/4#newcode142
Line 142: except:
We probably want to catch AssertionError and OsError here.

http://codereview.appspot.com/79042/diff/1/4#newcode215
Line 215: """
Would it be possible to distinguish stdout and stderr when reading from the
process?

http://codereview.appspot.com/79042/diff/1/4#newcode238
Line 238: pass
The function sends by default SIGTERM to the process. In such cases, what do we
do with misbehaving (hang) processes? Just leave it as it is and close other
file descriptors? Wouldn't be interesting to send a SIGKILL if another signal
doesn't work?

http://codereview.appspot.com/79042/diff/1/4#newcode279
Line 279: return True
Isn't risky to just return True if we can't find the PID under /proc?