Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1362571
| From | Cyrill Gorcunov <gorcunov@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data |
| Date | 2016-03-22 12:10 +0100 |
| Message-ID | <rfsmf-3ve-57@gated-at.bofh.it> (permalink) |
| References | <rbSIi-7nR-11@gated-at.bofh.it> <rdxq2-2bN-17@gated-at.bofh.it> <rdAHg-4j7-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [RFC] tty: n_tty -- Add new TIOCPEEKRAW ioctl to peek unread data Cyrill Gorcunov <gorcunov@gmail.com> - 2016-03-22 12:10 +0100
csiph-web