potential errors from sys::io_uring_enter usually being ignored about tokio-uring

[Noah-Kennedy]

I think we can try and handle some of these. EGAIN and EBUSY should be doable for instance. Most of these should just be panics though.

[FrankReh]

@Noah-Kennedy Sounds good. I'll work on that soon.

That begs the question whether submit_with in

tokio-uring/src/driver/op.rs

Lines 61 to 91 in 913aa14

	pub(super) fn submit_with<F>(data: T, f: F) -> io::Result<Op<T>>
	where
	F: FnOnce(&mut T) -> squeue::Entry,
	{
	driver::CURRENT.with(|inner_rc| {
	let mut inner_ref = inner_rc.borrow_mut();
	let inner = &mut *inner_ref;
	// If the submission queue is full, flush it to the kernel
	if inner.uring.submission().is_full() {
	inner.submit()?;
	}
	// Create the operation
	let mut op = Op::new(data, inner, inner_rc);
	// Configure the SQE
	let sqe = f(op.data.as_mut().unwrap()).user_data(op.index as _);
	{
	let mut sq = inner.uring.submission();
	// Push the new operation
	if unsafe { sq.push(&sqe).is_err() } {
	unimplemented!("when is this hit?");
	}
	}
	Ok(op)
	})
	}

should continue to return an io::Result.

An argument could be made that it future proofs it, even if there is no possible error returned right now, there might be in the future.

But I slightly favor changing the return type to simply Op<T>.

I don't have a feel for whether this would be considered a drastic change. The whole crate is still considered a POC I believe so breaking changes should still be acceptable.

[Noah-Kennedy]

Breaking changes are definitely acceptable at this stage if they move the API in a better direction.