On Fri, Mar 19, 2021 at 11:21 AM Josef Bacik <jo...@toxicpanda.com> 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 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