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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
> > On Fri, Mar 19, 2021 at 11:21 AM Josef Bacik <josef@xxxxxxxxxxxxxx> wrote:
> > >
> > > 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@xxxxxxxxxxxxxxxxxxx/
> 
> 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.
> 
> > 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].
> 
> > 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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux