On Thu, Jan 15, 2009 at 01:28:37PM +0000, Daniel P. Berrange wrote:
+libexec_PROGRAMS = virt-console
This can just be bin_PROGRAMS - not need to hide it outside of /usr/bin - its fine to let users just run virt-console directly if they wish
Solaris policy is not to introduce plumbing into the user's PATH. virt-console is undocumented and there is no advantage to running it directly. If it were in PATH we would have to document it, and we have no intention of doing that...
We need to add an explicit argument to turn on the automatic reconnect of VMs when they reboot. Existing apps calling virsh console rely on its current semantics which are to exit upon domain reboot and we can't break them
We argued about this last time. Looks like we'll have to keep this change private, and let Linux users suffer. Oh well :)
I'd suggest that when tracking across reboots, we should wait forever by default, and hav an optional timeout arg if you want to make it only wait 10 seconds.
-r | --reconnect reconnect when a VM reboots -t | --timeout=N exit if VM hasn't started after N seconds
Finally, if we're waiting after reboots, it seems sensible to also have the ability for wait for initial startup
-w | --wait wait for VM to start if not running
That lets people launch virt-console before they start the VM for the first time, so they can catch initial mesages easily.
Sure.
+ if (tcgetattr(ttyfd, &ttyattr) < 0) { + ioctl(ttyfd, I_PUSH, "ptem"); + ioctl(ttyfd, I_PUSH, "ldterm"); + tcgetattr(ttyfd, &ttyattr); + } + + cfmakeraw(&ttyattr); + tcsetattr(ttyfd, TCSANOW, &ttyattr); +#endif
The caller of open_tty() is also doing the getattr/makeraw/setattr operation, so this block appears to be redundant - just need to
Nope, that's on STDIN, not the pty slave. Stupid STREAMS semantics. regards john