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