Date: Tue, 22 Mar 2016 14:00:30 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Peter Hurley <peter@hurleysoftware.com>, 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
Message-ID: <20160322110030.GR2231@uranus.lan>
References: <20160312141830.GM1989@uranus.lan>
 <56EA2CF2.8090801@hurleysoftware.com>
 <20160317073244.GR2231@uranus.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160317073244.GR2231@uranus.lan>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2555
Lines: 62

On Thu, Mar 17, 2016 at 10:32:44AM +0300, Cyrill Gorcunov wrote:
> 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.

Ping? Guys, are there some more arguments against this ioctl?
Or some way which I missed suitable for nondestructive read
from a buffer?

> 
> > 
> > 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.

	Cyrill