Linux 6.15 io_uring

[silvanshade]

This PR adds Linux 6.15 io_uring ops to IoringOp.

Related: sunfishcode/linux-raw-sys#156

I've included a temporary crates.io override for the corresponding upstream PR for linux-raw-sys.

Note that this PR also fixes a SIGSEGV crash that occurs if you try to debug print io_uring_probe or IoringOp on a Linux 6.15 system with current release rustix.

It would be nice to gracefully handle missing constants for new ops, since just upgrading the kernel could cause a previously working program to crash, but it seems like it might require quite a lot of refactoring to achieve that. I guess it would need something like a catch-all Unknown variant and an explicit From impl to convert from numeric repr.

Is it generally understood that this is a problem to be aware of?

[sunfishcode]

This PR adds Linux 6.15 io_uring ops to IoringOp.

Related: sunfishcode/linux-raw-sys#156

I've included a temporary crates.io override for the corresponding upstream PR for linux-raw-sys.

I've now merged that and released linux-raw-sys 0.10.0.

Note that this PR also fixes a SIGSEGV crash that occurs if you try to debug print io_uring_probe or IoringOp on a Linux 6.15 system with current release rustix.

It would be nice to gracefully handle missing constants for new ops, since just upgrading the kernel could cause a previously working program to crash, but it seems like it might require quite a lot of refactoring to achieve that. I guess it would need something like a catch-all Unknown variant and an explicit From impl to convert from numeric repr.

Is it generally understood that this is a problem to be aware of?

No, it's a problem. The type is repr(u8) and non_exhaustive, so what if we added new Unused255, Unused254, Unused253, and so on to the enum, so that every possible u8 value is represented, and make them all doc(hidden) so that users won't see them and we can delete them as we add new opcodes?

[silvanshade]

I've now merged that and released linux-raw-sys 0.10.0.

Great. I'll update and remove the temporary override.

Is it generally understood that this is a problem to be aware of?

No, it's a problem. The type is repr(u8) and non_exhaustive, so what if we added new Unused255, Unused254, Unused253, and so on to the enum, so that every possible u8 value is represented, and make them all doc(hidden) so that users won't see them and we can delete them as we add new opcodes?

Yeah, that sounds like a good approach. I'll update the PR with a new commit that adds those hidden extra variants.

I'm also working on a PR (not submitted yet) for rustix-uring that adds all the missing ops and which needs some additions to the unions for io_uring_sqe. I think it makes sense to include those changes in this PR also in another commit. I'll do that and link the downstream PR once it's ready.

[silvanshade]

I've updated the PR with the extra hidden variants and also added some changes needed downstream as mentioned.

[silvanshade]

@sunfishcode Can you take a look at this and merge along with the related PRs?

Will require some coordination unless you are willing to modify the PRs directly and drop the commits which add the crate overrides, which would probably be easiest.

This fixes the crash on Kernel 6.15 and also enables all of the missing io_uring ops for rustix-uring.

upstream:

• Add more io_uring ZCRX definitions sunfishcode/linux-raw-sys#158

downstream:

• Add missing ops up to Linux 6.15 jordanisaacs/rustix-uring#23