Markus Armbruster <[email protected]> writes: > Paolo Bonzini <[email protected]> writes: > >> On 11/04/19 16:52, Markus Armbruster wrote: >>> char_pty_open() prints a "char device redirected to PTY_NAME (label >>> LABEL)" message to the current monitor or else to stderr. No other >>> ChardevClass::open() prints anything on success. Drop the message. >>> >>> Cc: "Marc-André Lureau" <[email protected]> >>> Cc: Paolo Bonzini <[email protected]> >>> Signed-off-by: Markus Armbruster <[email protected]> >>> Reviewed-by: Marc-André Lureau <[email protected]> >>> --- >>> chardev/char-pty.c | 2 -- >>> 1 file changed, 2 deletions(-) >>> >>> diff --git a/chardev/char-pty.c b/chardev/char-pty.c >>> index b034332edd..a48d3e5d20 100644 >>> --- a/chardev/char-pty.c >>> +++ b/chardev/char-pty.c >>> @@ -211,8 +211,6 @@ static void char_pty_open(Chardev *chr, >>> qemu_set_nonblock(master_fd); >>> >>> chr->filename = g_strdup_printf("pty:%s", pty_name); >>> - error_printf("char device redirected to %s (label %s)\n", >>> - pty_name, chr->label); >>> >>> s = PTY_CHARDEV(chr); >>> s->ioc = QIO_CHANNEL(qio_channel_file_new_fd(master_fd)); >> >> The reason for the message is that the char device is completely useless >> until the user knows the /dev/pts/N path[1]. You can get it with "info >> chardev" (aka query-chardev for QMP) but there's an interesting chicken >> and egg problem if the pty is for your monitor... >> >> Paolo > > During review of v1, I wrote: > > If we should decide the message is still useful enough to be worth > keeping, I could direct it to stdout instead of dropping it. > > No clear conclusion emerged, so I did nothing for v2. If we conclude to > keep the message now, I'll gladly do that.
No further comments, no clear conclusion, so let's stick to the status quo. I'll drop this patch and add one to print the message to stdout. [...]
