I summarized my understanding of Linux systems
1–10 of 88 posts
Re: I summarized my understanding of Linux systems
#2I think it needs three areas, not two:
1. User space
2. Kernel
3. Hardware/network
The kernel protects users from hardware, and hardware from users.
Re: I summarized my understanding of Linux systems
#3I think it needs three areas, not two: 1. User space 2. Kernel 3. Hardware/network The kernel protects users from hardware, and hardware from users.
This is reasonable and correct. I would also have found places in that map for: dcache, block devices, character devices, scheduler, page cache and console/tty/pty. The first two replace "filesystem hierarchy". The second and third are ancient and fundamental classes of UNIX devices.
Re: I summarized my understanding of Linux systems
#4I think it needs three areas, not two: 1. User space 2. Kernel 3. Hardware/network The kernel protects users from hardware, and hardware from users.
this is analagous to the fs hierarchy: root protects from the user
Re: I summarized my understanding of Linux systems
#5I can recommend taking a look at /proc and /sys, because that will clear up a lot of how things are intertwined and connected.
procfs is what's used by pretty much all tools that do something with processes, like ps, top etc.
The everything is a file philosophy becomes much more clear then. Even low level syscalls and their structs are offered by the kernel as file paths so you can interact with them by parsing those files as a struct, without actually needing to use kernel headers for compilation.
eBPF and its bytecode VM are a little over the top, but are essential to known about in the upcoming years cause a lot of tools is moving towards using their own bpf modules.
Re: I summarized my understanding of Linux systems
#6I can recommend taking a look at /proc and /sys, because that will clear up a lot of how things are intertwined and connected. procfs is what's used by pretty much all tools that do something with processes, like ps, top etc. The everything is a file philosophy becomes much more clear then. Even low level syscalls and their structs are offered by the kernel as file paths so you can interact with them by parsing those…
> The everything is a file philosophy becomes much more clear then.
To be honest, everything is a file is kind of a lie in unix. /proc and /sys are pretty much plan9 inspiration.
Re: I summarized my understanding of Linux systems
#7I can recommend taking a look at /proc and /sys, because that will clear up a lot of how things are intertwined and connected. procfs is what's used by pretty much all tools that do something with processes, like ps, top etc. The everything is a file philosophy becomes much more clear then. Even low level syscalls and their structs are offered by the kernel as file paths so you can interact with them by parsing those…
> The everything is a file philosophy becomes much more clear then. To be honest, everything is a file is kind of a lie in unix. /proc and /sys are pretty much plan9 inspiration.
Also, a lot of devices require very specific ioctl() commands to work with and don't provide everything as a file.
For example, you can't set the baudrate of a serial port by writing it to some /proc node.
Re: I summarized my understanding of Linux systems
#8My mental model of Linux does not have the CPU/Memory in user space. What am I missing?
Re: I summarized my understanding of Linux systems
#9I can recommend taking a look at /proc and /sys, because that will clear up a lot of how things are intertwined and connected. procfs is what's used by pretty much all tools that do something with processes, like ps, top etc. The everything is a file philosophy becomes much more clear then. Even low level syscalls and their structs are offered by the kernel as file paths so you can interact with them by parsing those…
> The everything is a file philosophy becomes much more clear then. To be honest, everything is a file is kind of a lie in unix. /proc and /sys are pretty much plan9 inspiration.
A more accurate term is that everything is a file descriptor.
The main difference is that plan9 uses read and write for everything, whereas Linux and BSD uses ioctls on file descriptors for everything.
Re: I summarized my understanding of Linux systems
#10My mental model of Linux does not have the CPU/Memory in user space. What am I missing?
Userspace program directly uses CPU and memory (unless you're using VM). In contrast to that, your userspace program does not directly access your network device or SSD, but uses kernel routines to access those indirectly.