RFC: 0-copy support for writing reads

[vlovich]

If I'm copying from 1 file to another, currently I have to allocate a DmaBuffer & copy_from_slice the ReadResult into the DmaBuffer. @glommer would it make sense to extend DmaBuffer to have a From<ReadResult> trait and extend it's internal storage enum to hold a ReadResultInner? Or is this a bad idea for some reason?

While I'm at it, does it make sense to extend the write method to be generic over some trait to allow the input for the write to be just a plain old byte slice that only needs to outlive the duration of the write?

[glommer]

As long as ownership is clear, I don't see anything wrong with that. By the time it materializes on our side, the kernel is done with it already so there's no risk there.

The second one is more complex. I had issues before with the kernel and us not agreeing with what "the duration of the write" is. The standard poll methods are bad for it, because they don't guarantee that the same buffer is used in two invocations if the write doesn't complete. If we go for a specialized API, may work.

[vlovich]

I'm not sure I follow the explanation about the second case. You're saying the completion event comes back but the kernel keeps using the referenced buffer? I'm sure I'm understanding that wrong because that would apply equally to the DmaBuffer case I would imagine which needs to know when to free the underlying buffer.

It sounds like something more nuanced though because you mention a second write and polling but I'm not familiar enough with io_uring to follow. What do you mean by specialized API?