Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1362571 > unrolled thread

Re: [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data Cyrill Gorcunov <gorcunov@gmail.com> - 2016-03-22 12:10 +0100

#1362571 — Re: [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data

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

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web