Builder API for uring operations

[FrankReh]

A place to talk about our wishes and ideas for a uring operation builder.

[FrankReh]

Do we really want a design that employs two layers of builder, neither one is actually working with the sqe bits so it would really be like having three levels. Or can we have one that starts by either reserving, with a guard, an actual spot in the squeue or creating a blank sheet representing an SQE, and then providing methods for adding bits to the SQE.

And when I say it might have two layers of builder, I mean one used by tokio-uring and one in io-uring. If we aren't careful, there will be an additional one for the public APIs found in the fs and net directories to get to the internal ones in the io directory.

[FrankReh]

Prior discussions have taken place in these Issues and PRs.

• Reconsider API design #86
• possibly deferring work in the creation of an operation #120
• Defer work until polled #165
• Support for Linking Ops #169
• Add a Builder framework #171

[FrankReh]

One meta idea: if we want to show possible code in more PRs, we can pick a single operation and implement it alongside everything else in the repo, reducing the amount of work to write it and to review and comment on it. Not even replacing a command like read, but just adding a new one like read2 that is, or comes with, a builder API.

[FrankReh]

On the subject for any of the read and write builders, I would like to consider how a read_exact builder option and a write_all builder option, respectively, could be supported.

There is a lot of work in setting things up for the exact and all versions that can be avoided if they are handled at a lower more common layer.

[ollie-etl]

There are 2 things here i believe.

1. figuring out on a per-op basis what builders ops should have to rationalise the many options the ops can have
2. Figuring out, probably globally how to let the builders give fine grained granularity over queue submission / op linkage

[FrankReh]

1. figuring out on a per-op basis what builders ops should have to rationalise the many options the ops can have

An option I would be comfortable with would be a macro, that took enum variants, or strings, to define the methods to the builder that should be available for modifying the op being passed to io-uring or that would modify the sqe that resulted from the io-uring op builder.

2. Figuring out, probably globally how to let the builders give fine grained granularity over queue submission / op linkage

I don't have a good feel for this one. Seems like it would require changes to io-uring but you and Noah have given this more thought.