Earlier quoted context omitted.
io_uring is a security nightmare.
How so?
you give process direct access to a piece of kernel memory.
its a reason why there is separation. thats all.
lsr: ls with io_uring
51–60 of 177 posts
Re: lsr: ls with io_uring
#52This seems more interesting as demonstration of the amortized performance increase you'd expect from using io_uring, or as a tutorial for using it. I don't understand why I'd switch from using something like eza. If I'm listing 10,000 files the difference is between 40ms and 20ms. I absolutely would not notice that for a single invocation of the command.
Re: lsr: ls with io_uring
#53Earlier quoted context omitted.
> Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? Good luck getting that upstreamed and accepted. The more foundational the tools (and GNU coreutils definitely is foundational), the more difficult that process will be. Releasing a standalone utility makes iteration much faster, partially because one is not bound to the release cycles of distributions.
In the history of Unix its also a common way to propose tool replacements, for instance how `less` became `more` on most systems, or `vim` became the new `vi` which in its day became the new `ed`.
> instance how `less` became `more` on most systems
How `more` became `less`.
The name of 'more' was from paging - rather than having text scroll off the screen, it would show you one page, then ask if you wanted to see 'more' and scroll down.
'less' is a joke by the less authors. 'less is more' etc.
Re: lsr: ls with io_uring
#54Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? It seems pretty annoying to have to install replacements for the most basic command line tools. And especially in this case, where you do not even do it for additional features, just for getting the exact same thing done a bit faster.
[dead]
Re: lsr: ls with io_uring
#55Earlier quoted context omitted.
Is there a noticeable benefit of this huge syscall reduction?
Yes I just checked it after installing strace strace -c ls gave me this 100.00 0.002709 13 198 5 total strace -c eza gave me this 100.00 0.006125 12 476 48 total strace -c lsr gave me this 100.00 0.001277 33 38 total So seeing the number of syscalls in the calls directory 198 : ls 476 : eza 33 : lsr A meaningful difference indeed!
That's just observing there is a difference, not explaining why that's a good thing.
Re: lsr: ls with io_uring
#56Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? It seems pretty annoying to have to install replacements for the most basic command line tools. And especially in this case, where you do not even do it for additional features, just for getting the exact same thing done a bit faster.
The author answered on lobster thread [1]. This is more of an io_uring exercise than an attempt to replace ls.
Re: lsr: ls with io_uring
#57Earlier quoted context omitted.
> Releasing a standalone utility makes iteration much faster, partially because one is not bound to the release cycles of distributions. which certainly is a valid way or prioritizing. similarly, distros/users may prioritize stability, which means the theoretical improvement would now be stuck in not-used-land. the value of software appears when it's run, not when it's written
> the value of software appears when it's run, not when it's written Have you ever tried to contribute to open source projects? The question was why wouldn't someone writing software not take the route likely to end in rejection/failure. I don't know about you, but if I write software, I am not going to write it for a project whose managers will make it difficult for my PR to be accepted, and that 99% likely it never…
> Have you ever tried to contribute to open source projects?
yes, and it was often painful enough to make me consider very well wether I want to bother contributing. I can only imagine how terrible the experience must be at a core utility such as ls.
> The question was why wouldn't someone writing software not take the route likely to end in rejection/failure
Obviously they wouldn't - in my comment I assumed that the lsr author aimed for providing a better ls for people and tried to offer a perspective with a different definition of what success is.
> I don't like being jerked around by management, especially when I'm doing it for free
I get that. The older OSS projects become, the more they fossilize too - and that makes it more annoying to contribute. But you can try to see it from the maintainers perspective too: They have actual people relying on the program being stable and are often also not paid. Noone is forcing you to contribute to their project, but if you don't want to deal with existing maintainers, you won't have their users enjoying your patchset. Know what you want to achieve and act accordingly, is all I'm trying to say.
Re: lsr: ls with io_uring
#58Re: lsr: ls with io_uring
#59I wonder how it performs against an NFS server with lots of files, especially one over a kinda-crappy connection. Putting an unreliable network service behind blocking POSIX syscalls is one of the main reasons NFS is a terrible design choice (as can be seen by anyone who's tried to ctrl+c any app that's reading from a broken NFS folder), but I wonder if io_uring mitigates the bad parts somewhat.
Samba too
Re: lsr: ls with io_uring
#60Earlier quoted context omitted.
How so?
you give process direct access to a piece of kernel memory. its a reason why there is separation. thats all.
Most of the security concerns with io_uring that I've seen aren't related to the shared buffers at all but simply stem from the fact that io_uring is a mechanism to instruct the kernel to do stuff without making system calls, so security measures that focus on what system calls a process is allowed to do are ineffective.