more intuitive return code for unsupported operations?

[carns]

I recently wrote some prototype liburing code on my laptop, did some brief tests, then began testing it on a second system. The code that had previously worked on my laptop returned -22 (EINVAL) from a write operation that I submitted using io_uring_prep_write() on the second system.

I stared at my code for a while trying to figure out how I could have gotten the arguments wrong to something as simple as a write call (i.e., the kinds of things listed in the write() man page), before finally digging into code and realizing that the kernel on the 2nd system simply didn't support IORING_OP_WRITE.

No big deal, I can of course adjust my code to use WRITEV or WRITE_FIXED. I also understand why the cqe would set the result to EINVAL, because technically the sqe indeed had an invalid opcode for that kernel.

All the same, I believe the problem would have dawned on me sooner if this had somehow been indicated with a different code (maybe EOPNOTSUPP? I dunno) that isn't also a common error code for the underlying operation type that I was trying to issue.

Thoughts?

[axboe]

Yeah, -EINVAL is generally awful... Though at this point we're pretty much stuck with that.

But if you don't have IORING_OP_WRITE, then please do upgrade, you are on something ancient and generally unsupported.

[carns]

Ok, I figured it was worth a shot to bring up :)

Boy howdy, do I wish it could be upgraded. It's not likely in the short term, though.