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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.