public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Jiri Slaby <jslaby@suse.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrey Vagin <avagin@virtuozzo.com>,
	Pavel Emelianov <xemul@virtuozzo.com>,
	Vladimir Davydov <vdavydov@virtuozzo.com>,
	Konstantin Khorenko <khorenko@virtuozzo.com>
Subject: Re: [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data
Date: Thu, 17 Mar 2016 10:32:44 +0300	[thread overview]
Message-ID: <20160317073244.GR2231@uranus.lan> (raw)
In-Reply-To: <56EA2CF2.8090801@hurleysoftware.com>

On Wed, Mar 16, 2016 at 09:05:06PM -0700, Peter Hurley wrote:
> > Here is a new ioctl code which simply copies data from read buffer
> > into the userspace without any additional processing (just like
> > terminal is sitting in a raw mode).
> 
> Maybe I'm overlooking something obvious, but why not do just that;
> ie., save the termios, reset termios to raw mode and read the entire
> ldisc read buffer?
> 
> Note that saving and resetting termios to raw mode is only necessary
> for the slave side, as the master side is always in raw mode.

Hi Peter! Yes we can do that, but there is one significant problem:
when we read the buffer (draining it) and then during later stages
of checkpoint something fails -- we need to bring the dumping program
back to the former state so it won't notice that someone has been
dumping it. Which means code flow like

 - read ldisk buffer
 - ... some other work for checkpoint sake ...
 - ... obtained some error ...
 - write ldisk buffer back to restore original content

and if here write fails (for any reason), the program being
dupmed will loose ldisk buffer content. we simply can't allow
this to happen because otherwise checkpoint will work in
destructive way.

Moreover there is an option in criu where we allow to dump
program and leave it in running state, say someone needs
a snapshot of a state, thus we always must work in non-
destructive manner.

Sure, not modifying the kernel would be a preferred way
for me too.

> 
> Then, two options for restore are:
> 1) set termios to raw mode, write to peer, restore the saved termios; or
> 2) restore the saved termios and write to peer.
> 
> option 1 will preserve the contents as read but not preserve the line
> termination state; ie., it will be possible to read multiple lines
> with a single canonical read.
> 
> option 2 will preserve the line termination state (for the most part)
> but not necessarily the contents which might be re-interpreted.
> 
> These two options are not necessarily exclusive; it may be possible
> to construct a mixed mode for restore based on the original saved
> termios that reconstitutes both line termination state and read buffer
> contents.
> 
> One thing not accounted for is the column position.

  reply	other threads:[~2016-03-17  7:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-12 14:18 [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data Cyrill Gorcunov
2016-03-13 10:14 ` Jiri Slaby
2016-03-13 10:35   ` Cyrill Gorcunov
2016-03-16  9:48     ` [PATCH v2] " Cyrill Gorcunov
2016-03-17  4:05 ` [RFC] " Peter Hurley
2016-03-17  7:32   ` Cyrill Gorcunov [this message]
2016-03-22 11:00     ` Cyrill Gorcunov

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=20160317073244.GR2231@uranus.lan \
    --to=gorcunov@gmail.com \
    --cc=avagin@virtuozzo.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=khorenko@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter@hurleysoftware.com \
    --cc=vdavydov@virtuozzo.com \
    --cc=xemul@virtuozzo.com \
    /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