I'm a little confused on how this tutorial somehow explains several tasks at completely different levels of difficulty (setting up a VM, installing a compiler v

I'm a little confused on how this tutorial somehow explains several tasks at completely different levels of difficulty (setting up a VM, installing a compiler via apt-get, modifying/updating the bootloader, building a custom kernel, and finally creating a new syscall) with a relatively constant depth of explanations. It's difficult for me to judge the usefulness of this guide because I'm familiar with those steps, but I'm wondering if it might have been better to define a more narrow scope for this tutorial with certain prerequisites, and going into detail about the ramifications of adding a new syscall? Especially since I feel the guide barely mentions a few interesting details: 1. Only arch/x86/entry/syscalls/syscall_64.tbl is modified in this tutorial, glossing over the fact that that file only affects x86_64 syscalls (disclaimer: I'm 90% sure on this one, but don't quote me on this). Of course I wouldn't expect the tutorial to explain how to modify all the architecture-specific files, but I'd say this fact is worth noting. 2. The user-space story: The post doesn't mention how to actually use this syscall - even though that's one of the critical parts of a syscall. Essentially, if you call open() in a C program, you're not actually issuing any syscall directly. Rather the C library (e.g. glibc) implements an open() function that internally performs the syscall. This is primarily because many syscalls don't map 1:1 to C library functions, in addition to some differences between platforms and architectures. So if you'd want to use the syscall you'd have to implement a syscall wrapper yourself or use the low-level syscall(2) [1] function that allows you to access system calls not provided by glibc. There is also some political drama attached to this, essentially the glibc maintainers don't want to implement/provide functions for certain Linux syscalls because of certain reasons (IIRC it's mostly about portability concerns, but I think there are some syscalls that the glibc maintainers just don't like for whatever reason). 3. The "What if you really wanted to add a syscall to Linux?" story, which boils down to: The Linux maintainers don't want to add any new syscalls except in very few cases (because syscalls generally can't be changed once they're introduced). Instead, you're supposed to use more flexible kernel interfaces, such as sysfs or debugfs (or previously, ioctl and procfs, but they're frowned upon nowadays and only used in certain areas). See the Linux documentation on adding syscalls [2]. [1] https://man7.org/linux/man-pages/man2/syscall.2.html https://man7.org/linux/man-pages/man2/syscall.2.html [2] https://www.kernel.org/doc/html/v5.14/process/adding-syscalls.html https://www.kernel.org/doc/html/v5.14/process/adding-syscall...