Really really amazing talk! One of the rare ones where you get taught things you didn't even know you wanted to learn. Ryan is a treasure, for real. Many thanks!
Wow, this was amazingly informative! Thank you so much, Ryan! Especially awesome: You always help to orient after each section, and at the end of the talk. This helps tremendously to put the pieces together in one's head!
Small note: "All the shell does is to call exec*()." It calls fork() before it, because exec*() _replaces_ the currently running process with the new binary. And between fork() and exec*() the shell might set up stdio redirection and such. Linux does not have a system call that does both in one, which can be a problem for huge processes, because while the cloned memory is copy on write, the page-tables need to be copied, and if those alone are huge it is still a heavy operation. They say its a problem for PostgreSQL and why you should limit connections to your PostgreSQL server? There is the posix_spawn() function, but under Linux it just does fork()+exec*(). Some BSDs actually implement posix_spawn() as system call. I think Windows only has something like that and no way to exec*() without spawning a new process.
This is really cool. Where can I learn about what a shell does before calling fork + exec* apart from stdio redirectioons. I heard some shells handle signals as well.
As an assembly language geek and a fan of `#![no_std]` ... this was always a favourite topic of mine even before Rust came along. I love that "Not necessarily wrong... just a bit too simple".
9:06 why does cargo/rustc have to statically embed entirety of standard library into final binary, and not only used elements, since it should know which of those are actually used?
The vdso basically is a couple of system calls that are loaded into the process space so that the application can call those without having to actually make the system call "dance" as it were, no going into kernel space for it. For instance, I think gettimeofday or something like that, lives there. Why is this important? Its because system calls are a lot more costly than normal user space function calls. So, pulling these small syscalls into the process space, removes the need for context switching back and forth between user space and kernel space, making those calls almost equivalent to a normal function call.
Interesting. So, these syscalls are executed without the need for ring0. May I ask what are these syscalls and how does kernel know before hand the arguments for these syscalls?
Really really amazing talk! One of the rare ones where you get taught things you didn't even know you wanted to learn. Ryan is a treasure, for real. Many thanks!
Wow, this was amazingly informative! Thank you so much, Ryan!
Especially awesome: You always help to orient after each section, and at the end of the talk. This helps tremendously to put the pieces together in one's head!
It would be nice if the resource links at the end of the talk were in the youtube description too. But great talk btw!
Yeah, makes sense! I updated the description
Thanks❤
Incredible talk, would love to learn more in this direction, keep it coming Ryan!
One of the best, if not the best, I’ve watched on TH-cam so far. Thanks!
5:30 in, and already very valuable! Thanks, Ryan!
Small note: "All the shell does is to call exec*()." It calls fork() before it, because exec*() _replaces_ the currently running process with the new binary. And between fork() and exec*() the shell might set up stdio redirection and such.
Linux does not have a system call that does both in one, which can be a problem for huge processes, because while the cloned memory is copy on write, the page-tables need to be copied, and if those alone are huge it is still a heavy operation. They say its a problem for PostgreSQL and why you should limit connections to your PostgreSQL server? There is the posix_spawn() function, but under Linux it just does fork()+exec*(). Some BSDs actually implement posix_spawn() as system call. I think Windows only has something like that and no way to exec*() without spawning a new process.
This is really cool. Where can I learn about what a shell does before calling fork + exec* apart from stdio redirectioons. I heard some shells handle signals as well.
This was extraordinarily illuminating. Thank you! I’m grateful
As an assembly language geek and a fan of `#![no_std]` ... this was always a favourite topic of mine even before Rust came along.
I love that "Not necessarily wrong... just a bit too simple".
9:06 why does cargo/rustc have to statically embed entirety of standard library into final binary, and not only used elements, since it should know which of those are actually used?
Wow, such a nice intro. After half a minute I am really interested in the content of the talk.
great presentation, thanks
I like that he basically gives therapy for people with impostor syndrome for the first few minutes.
"My life is very much consumed by Rust" :)
The vdso basically is a couple of system calls that are loaded into the process space so that the application can call those without having to actually make the system call "dance" as it were, no going into kernel space for it. For instance, I think gettimeofday or something like that, lives there. Why is this important? Its because system calls are a lot more costly than normal user space function calls. So, pulling these small syscalls into the process space, removes the need for context switching back and forth between user space and kernel space, making those calls almost equivalent to a normal function call.
Interesting. So, these syscalls are executed without the need for ring0. May I ask what are these syscalls and how does kernel know before hand the arguments for these syscalls?
Fantastic very informative talk!
Fantastic talk
great talk
Excellent presentation and content!
very clear
Wonderful talk!!!!
This is a great resource, thanks a lot!
Great talk, thanks!
Great talk. 🤩
I think it spells exec-ve (arg Vector and Env), not exe-cve
__start -> __lib_start_main -> main
But if we don't have a main in our Rust program anymore, how can this work?
Can you do some more talks?
Thanks 👍
Great presentation, thank you. Also very informative content.
I do not use Cargo too.
13:41 My whole life is a lie.
Who knows how to do this in MacOS M1?
You say “stood” for “std”?