Re: [PATCH v2 2/2] io_uring/timeout: immediate timeout arg

[Pavel Begunkov <asml.silence@gmail.com>]

On 2/27/26 22:19, Jens Axboe wrote:
...
>> They should be enabled in the same release, but we've been rather
>> discussing the way to do that. I was saying that u64 is enough to
>> pass the abs timeout value, and we can extend it to another u64 if
>> needed in several centuries from now. And it's not a bad option
>> because plain u64 ns makes much much more sense for the relative
>> mode. And even for the abs scenario above, I'd prefer that rather
>> than doing second adjustments every single time.
> 
> ABS makes very little sense as nanoseconds, that's pretty confusing on
> the userspace side. That's the main issue.
> 
> I'm not sure why it's such a big deal to just encode the sec/nsec so
> that userspace can use it directly from a timespec or timeval which is
> most likely what they are querying time from anyway? If you do absolute,
> surely you'd do
> 
> get_time(&t);
> t.tv_sec += 1;

More like +N ms, which would be

t.tv_sec += N / 1000;
t.tv_nsec += (N % 1000) * NS_IN_MS;
if (t.tv_nsec >= NS_IN_SEC) {
	t.tv_nsec -= NS_IN_SEC;
	t.tv_sec++;
}

And then you want to compare them and calculate differences. io_uring
works with __kernel_timespec, but just take a look at liburing
tests/examples, lots of them open code some version of
get_time_[m,u,n]s unless they hard code a specific relative timeout.
It's a self propelling misery.

> now issue timeout for that. That's a hell of a lot more natural to use
> than converting to and from nsecs.

I'd rather convert it to ns once and use that after. And I bet it'll
be nicer with other non Linux specific libraries. e.g. you can get
ns from std c++.

> For relative it's obviously not a huge deal, but it'd be nice to keep
> them consistent.
> 

-- 
Pavel Begunkov