[PATCH] update stubdom config example

[PATCH] update stubdom config example

[Stefano Stabellini]

Hi all,
this patch updates the stubdom config example to reflect that the serial
option can now be used.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

---

diff -r 81ca5d5b2ad3 tools/examples/xmexample.hvm-stubdom
--- a/tools/examples/xmexample.hvm-stubdom	Tue Jun 16 13:27:35 2009 +0100
+++ b/tools/examples/xmexample.hvm-stubdom	Tue Jun 16 13:32:07 2009 +0100
@@ -178,9 +178,11 @@
 #-----------------------------------------------------------------------------
 #   serial port re-direct to pty deivce, /dev/pts/n 
 #   then xm console or minicom can connect
-# 
-# STUBDOM: always disable as the stub domain doesn't have access to dom0's
-# ptys
+#
+#   In the stubdoms case this option adds a secondary console to the
+#   stubdom because there is always one for logging.
+#   To connect to the guest serial you can use "xm console -n 1"
+#   followed by the domain name of the stubdom.
 #serial='pty'

Re: [PATCH] update stubdom config example

[Samuel Thibault]

Stefano Stabellini, le Tue 16 Jun 2009 16:46:17 +0100, a écrit :
> this patch updates the stubdom config example to reflect that the serial
> option can now be used.

Ok, so now I see what your previous patch is for :) I still think
openpty() shouldn't be used, as a standard function with the same name
but different prototype exists, that would lead us to troubles. I would
rather see it as open("/dev/ptmx") and/or posix_openpt(), which actually
does the same, but can be interfaced in a standard way. And then we
could even implement pts_name() to provide the console frontend path.

Samuel

Re: [PATCH] update stubdom config example

[Stefano Stabellini]

Samuel Thibault wrote:

> Stefano Stabellini, le Tue 16 Jun 2009 16:46:17 +0100, a écrit :
>> this patch updates the stubdom config example to reflect that the serial
>> option can now be used.
> 
> Ok, so now I see what your previous patch is for :) I still think
> openpty() shouldn't be used, as a standard function with the same name
> but different prototype exists, that would lead us to troubles. I would
> rather see it as open("/dev/ptmx") and/or posix_openpt(), which actually
> does the same, but can be interfaced in a standard way. And then we
> could even implement pts_name() to provide the console frontend path.
> 

I wasn't aware of posix_openpt, I think that is the best choice.
I'll resend the patch and also update the qemu patch that uses it.