qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 03/15] char-pty: Drop "char device redirected


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 03/15] char-pty: Drop "char device redirected to" message
Date: Wed, 17 Apr 2019 20:09:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Markus Armbruster <address@hidden> writes:

> Paolo Bonzini <address@hidden> 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" <address@hidden>
>>> Cc: Paolo Bonzini <address@hidden>
>>> Signed-off-by: Markus Armbruster <address@hidden>
>>> Reviewed-by: Marc-André Lureau <address@hidden>
>>> ---
>>>  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.

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]