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.
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?
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.
So make the UAPI explanation for this horror be in a legible format
that is actually part of the kernel so that I can read what the intent
is, instead of having to decode hieroglypics.
Linus
