From: Peter Hurley <peter@hurleysoftware.com>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: Nan Li <nli@suse.com>,
gregkh@linuxfoundation.org, jslaby@suse.cz,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] pty: BREAK for pseudoterminals
Date: Mon, 16 Feb 2015 14:01:00 -0500 [thread overview]
Message-ID: <54E23E6C.4030306@hurleysoftware.com> (raw)
In-Reply-To: <54E23748.8090801@hurleysoftware.com>
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@hurleysoftware.com> wrote:
>>> On 02/16/2015 08:22 AM, Petr Tesarik wrote:
>>>> On Mon, 16 Feb 2015 08:04:02 -0500
>>>> Peter Hurley <peter@hurleysoftware.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.
next prev parent reply other threads:[~2015-02-16 19:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 19:11 [PATCH 1/1] pty: BREAK for pseudoterminals Nan Li
2015-02-16 13:04 ` Peter Hurley
2015-02-16 13:22 ` Petr Tesarik
2015-02-16 16:24 ` Peter Hurley
2015-02-16 17:16 ` Petr Tesarik
2015-02-16 18:30 ` Peter Hurley
2015-02-16 19:01 ` Peter Hurley [this message]
2015-02-17 19:03 ` Peter Hurley
2015-02-18 7:05 ` Petr Tesarik
2015-02-23 10:53 ` One Thousand Gnomes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E23E6C.4030306@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=nli@suse.com \
--cc=ptesarik@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox