[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgoWjqMoEZ9A7N+MF+urrw2Vyk+PP_FW4BQLAeY9PWARQ@mail.gmail.com>
Date: Mon, 18 Jan 2021 11:36:47 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christoph Hellwig <hch@....de>
Cc: Oliver Giles <ohw.giles@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: Splicing to/from a tty
On Mon, Jan 18, 2021 at 12:16 AM Christoph Hellwig <hch@....de> wrote:
>
> On Sat, Jan 16, 2021 at 08:35:41PM +1300, Oliver Giles wrote:
> > For my case, I attempted to instead implement splice_write and splice_read in tty_fops; I managed to get splice_write working calling ld->ops->write, but splice_read is not so simple because the tty_ldisc_ops read method expects a userspace buffer. So I cannot see how to implement this without either (a) using set_fs, or (b) implementing iter ops on all line disciplines.
>
> set_fs is gone for all the important platforms. So yes, you basically
> need to convert to iov_iter or have a huge splice_write parallel
> infrastucture.
It might ok to try to limit it to just the pty cases and ldisc ops
that need it, apparently in this case pty (and presumably just one or
two line disciplines)
Of course, it probably would be really nice to try to convert
tty_read() to use the same model that we have for tty_write(), and
then make the ld->ops->read() function actually take a kernel buffer
instead.
I wonder how painful that would be.
Linus
Powered by blists - more mailing lists