mirror of
https://github.com/cloud-hypervisor/cloud-hypervisor.git
synced 2024-12-22 13:45:20 +00:00
b6feae0ace
When neither serial nor console are connected to the tty, cloud-hypervisor shouldn't touch the tty at all. One way in which this is annoying is that if I am running cloud-hypervisor without it using my terminal, I expect to be able to suspend it with ^Z like any other process, but that doesn't work if it's put the terminal into raw mode. Instead of putting the tty into raw mode when a VM is created or restored, do it when a serial or console device is created. Since we now know it can't be put into raw mode until the Vm object is created, we can move setting it back to canon mode into the drop handler for that object, which should always be run in normal operation. We still also put the tty into canon mode in the SIGTERM / SIGINT handler, but check whether the tty was actually used, rather than whether stdin is a tty. This requires passing on_tty around as an atomic boolean. I explored more of an abstraction over the tty — having an object that encapsulated stdout and put the tty into raw mode when initialized and into canon mode when dropped — but it wasn't practical, mostly due to the special requirements of the signal handler. I also investigated whether the SIGWINCH listener process could be used here, which I think would have worked but I'm hesitant to involve it in serial handling as well as conosle handling. There's no longer a check for whether the file descriptor is a tty before setting it into canon mode — it's redundant, because if it's not a tty it just won't respond to the ioctl. Tested by shutting down through the API, SIGTERM, and an error injected after setting raw mode. Signed-off-by: Alyssa Ross <hi@alyssa.is> |
||
---|---|---|
.. | ||
src | ||
Cargo.toml |