Thread (30 messages) 30 messages, 6 authors, 2021-03-20

Re: [PATCH v8 00/10] fs: interface for directly reading/writing compressed data

From: Christian Brauner <hidden>
Date: 2021-03-19 20:44:56
Also in: linux-btrfs, linux-fsdevel

On Fri, Mar 19, 2021 at 01:27:25PM -0700, Omar Sandoval wrote:
On Fri, Mar 19, 2021 at 01:08:05PM -0700, Linus Torvalds wrote:
quoted
On Fri, Mar 19, 2021 at 11:21 AM Josef Bacik [off-list ref] wrote:
quoted
Can we get some movement on this?  Omar is sort of spinning his wheels here
trying to get this stuff merged, no major changes have been done in a few
postings.
I'm not Al, and I absolutely detest the IOCB_ENCODED thing, and want
more explanations of why this should be done that way, and pollute our
iov_iter handling EVEN MORE.

Our iov_iter stuff isn't the most legible, and I don't understand why
anybody would ever think it's a good idea to spread what is clearly a
"struct" inside multiple different iov extents.

Honestly, this sounds way more like an ioctl interface than
read/write. We've done that before.
As Josef just mentioned, I started with an ioctl, and Dave Chinner
suggested doing it this way:
https://lore.kernel.org/linux-fsdevel/20190905021012.GL7777@dread.disaster.area/ (local)

The nice thing about it is that it sidesteps all of the issues we had
with the dedupe/reflink ioctls over the years where permissions checks
and the like were slightly different from read/write.
quoted
But if it has to be done with an iov_iter, is there *any* reason to
not make it be a hard rule that iov[0] should not be the entirely of
the struct, and the code shouldn't ever need to iterate?
For RWF_ENCODED, iov[0] is always used as the entirety of the struct. I
made the helper more generic to support other use cases, but if that's
the main objection I can easily make it specifically use iov[0].
quoted
Also I see references to the man-page, but honestly, that's not how
the kernel UAPI should be defined ("just read the man-page"), plus I
refuse to live in the 70's, and consider troff to be an atrocious
format.
No disagreement here, troff is horrible to read.
Not a fan of troff either: One thing that might help you a little bit is
to use pandoc to convert to troff. You can write your manpage in
markdown or rst and then convert it into troff via pandoc. Still might
require some massaging but it makes it considerably more pleasant to
write a manpage.

Christian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help