[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54E23E6C.4030306@hurleysoftware.com>
Date: Mon, 16 Feb 2015 14:01:00 -0500
From: Peter Hurley <peter@...leysoftware.com>
To: Petr Tesarik <ptesarik@...e.cz>
CC: Nan Li <nli@...e.com>, gregkh@...uxfoundation.org, jslaby@...e.cz,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] pty: BREAK for pseudoterminals
On 02/16/2015 01:30 PM, Peter Hurley wrote:
> On 02/16/2015 12:16 PM, Petr Tesarik wrote:
>> On Mon, 16 Feb 2015 11:24:16 -0500
>> Peter Hurley <peter@...leysoftware.com> wrote:
>>> On 02/16/2015 08:22 AM, Petr Tesarik wrote:
>>>> On Mon, 16 Feb 2015 08:04:02 -0500
>>>> Peter Hurley <peter@...leysoftware.com> wrote:
>>>>> On 02/05/2015 02:11 PM, Nan Li wrote:
[...]
>>> AFAICT this is simply for convenience, as sysrq functionality is
>>> already available via sendkey.
>>
>> That's a completely different story. This patch (after fixing it to
>> work with the terminal end) would allow me to set up a QEMU emulated
>> serial port using a pty (i.e. "-chardev pty") and send a BREAK signal
>> to it, no matter what is running in the guest.
>
>
>> I mean, I can run an emulated MIPS64 as a QEMU guest on an x86_64 host,
>> and still somehow pass SysRq to it. IIUC this will never be possible
>> with KVP.
Sorry about that; accidentally pressed send :/
I see this as a shortcoming of the emulation, not of the underlying
IPC used. I don't see why this couldn't be done in-band with any IPC.
>> Another use case: In my job, I'm struggling with different serial
>> consoles (some using ipmi SoL, some using telnet to a service
>> processor, some connected with a real RS-232 link). If I could send
>> BREAK over a pty, I could extend ipmiconsole to translate it to the SOL
>> message, telnet to translate it to the telnet escape, amtterm to send a
>> corresponding message... Then I could send a BREAK to any of my systems
>> simply by pressing 'C-A b' in screen(1) without having to think how is
>> this particular machine connected and what the correct sequence is for
>> that protocol.
I need to think more on this.
Regards,
Peter Hurley
PS - it's interesting that you mention a service processor, because the
hacked support for remote supervisor adapter is and has been the #1
barrier to splitting the 8250 driver. I literally have spent days trying
to come up with an acceptable solution.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists