Jens Axboe

Finally got around to updating my rw_iter branch, which currently has 471 patches and drops the legacy fops read/write non-iterating handlers. It boots and works here. See https://lwn.net/Articles/972081/ for details. When is the last time you saw a patch series diffstat look like this:

990 files changed, 12302 insertions(+), 12993 deletions(-)

The file_operations structure gets smaller

Kernel developers are encouraged to send their changes in small batches as a way of making life [...]

LWN.net
Mar 18 at 2:00amWeb
Show threadJens AxboeMar 18
This is the kind of shit that keeps @brauner up at night.
Show threadJens AxboeMar 18

This was my motivation:

io_uring/rw.c | 80 ++-------------------------------------------------------------
1 file changed, 2 insertions(+), 78 deletions(-)

Talk about being petty...

Show threadJosh TriplettMar 18
I think that comment from 2004 is not what you meant to link to. Missing a digit?
Show threadJens AxboeMar 18
@josh I fat fingered it initially, reload it and it should look correct. This is the link: https://lwn.net/Articles/972081/
The file_operations structure gets smaller

Kernel developers are encouraged to send their changes in small batches as a way of making life [...]

LWN.net
Show threadJosh TriplettMar 18
Edited posts don't always propagate; I still see the old version of your original post. Thanks for the updated link!
Show threadAndrew KelleyMar 18

@axboe

> When is the last time you saw a patch series diffstat look like [many changes]

let's see... last week! https://codeberg.org/ziglang/zig/pulls/31403

😁

compiler: rework type resolution

This branch implements a major rework of the Zig compiler's type resolution system. # Background The logic for type resolution in the Zig compiler has, over time, built up a collection of hacks which work to solve specific use cases. Unfortunately, the approaches used are deeply flawed and lead...

Codeberg.org
Show threadJens AxboeMar 18
@andrewrk 71 patches? Please! Unfortunately can't see a diffstat in that UI, but I believe you 😉
Show threadAndrew KelleyMar 18

@axboe

271 files changed, 26975 insertions(+), 33509 deletions(-)

(all changes made individually by hand)

Show threadJens AxboeMar 18
@andrewrk Mine were made by hand too, but last update was 6.12-something. I did have claude help me rebase it and look for new spots to make it current, saved me a lot of rebasing pain.
Show threadJens AxboeMar 18
@andrewrk Oh and you gotta love diffstats like that, killing way more code than what is being added!
Show threadAndrew KelleyMar 18
@axboe agreed. thank you for your excellent work on io_uring. I think after this next zig release, we will see many zig users trying out io_uring, because it will be just two lines in main() function swapped to use io_uring for all I/O across the entire std lib (and also all dependency packages across the entire ecosystem)
Show threadJens AxboeMar 18
@andrewrk Love it! Thank YOU for paving the way on the language front. I need to set aside some time to write something in zig - both in general, but also to play with the io_uring implementation.
Show threadAnisseMar 18
@axboe random thought: isn't this just moving two pointers out of fops to more code in each driver's .text section?
Show threadJens AxboeMar 18

@Aissen Main motivation here is to avoid having two sets of read or write handlers, as the iter variants fully support everything and the old school ones don't support proper async IO and things like non-blocking IO on a per-IO basis. Eg the latter rely per-file flags rather than per-IO flags.

As an example, on my r7625 test box, my vmlinux shrinks by about 86K in size. Can go down more, as fops helpers get dropped with conversions.

Show threadJens AxboeMar 18
@Aissen Outside of that, it's just classic tech debt removal on a larger scale. Consider why iter variants of the read/write handlers were added in the first place. Arguably the work of converting everything to the new iter style handlers should've been done then, but it was not. And then you're stuck with 2 sets of each.
Show threadAnisseMar 18
@axboe very interesting feedback, thanks!