3 ms·
Most of that was when the team was pretty tiny. It was fun starting from when the kernel was just beginning to run userspace code. I'm still very happy with h
by swetland 3y ago
Most of that was when the team was pretty tiny. It was fun starting from when the kernel was just beginning to run userspace code. I'm still very happy with how the syscalls turned out. If I did it again, I'd stick with a (small) monolithic kernel though -- makes a lot of things simpler.
- nextaccountic 3y agoit's my impression that fuschia syscalls work like linux's vDSO. why don't linux use vDSO for more things?
- deleted 3y ago[deleted]
- yencabulator 3y agovDSO doesn't provide a security boundary. vDSO basically provides a pure-userspace fastpath for syscalls, only making the real syscall if necessary. It's great for low-overhead read-only calls that cache well and that you're always allowed to do, like clock_gettime(2) -- but not much more. You can't implement all syscalls as vDSO; if it's a vDSO the goal is to not make an actual syscall at all. Fuchsia might use vDSO-style things more as a way to replace the glibc-style syscall stubs, abstracting away the actual syscall ABI? That doesn't remove the actual syscall. > why don't linux use vDSO for more things? vDSO is much more complex to manage than traditional syscalls, can't be used for anything except pure read always allowed things, etc. As for optimizing syscalls, it seems things are moving more toward io_uring and ringbuffers of messages going in/out of the kernel, with very few syscalls made after setup.
- swetland 3y agoThe intent behind the vDSO style interface for syscalls in Fuchsia was primarily to avoid baking specific syscall mechanisms into the ABI, hopefully to allow future changes to the mechanism without breaking binary compatibility -- which was defined as ELF linkage against libzircon.so.