Nice! I want to do something similar and map my understanding of Linux. I find some diagrams on Wikipedia fascinating (example: https://en.m.wikipedia.org/wiki/File:Linux_Graphics_Stack_20..., but more to do with the user library ecosystem rather than kernel and program runtime). These diagrams make me want to learn about each part and be able to comprehend in principle what is happening on my machine. Eventually...
I summarized my understanding of Linux systems
21–30 of 88 posts
Re: I summarized my understanding of Linux systems
#22I don't understand what the boxes on this diagram are meant to represent.
It feels like an elaborate mechanism to draw something wrong in the hopes people will correct it.
Re: I summarized my understanding of Linux systems
#23My mental model of Linux does not have the CPU/Memory in user space. What am I missing?
Nor does mine. Userspace assembly runs directly on the CPU* executing in the unprivileged ring. When the userspace program makes a system call by calling a kernel entry function which is mapped into the process's address space by the dynamic loader, then part of that entry into kernelspace is to put the CPU into the privileged ring and kernel assembly then runs on the CPU. The process scheduler can stop execution to…
> execute assembly
I always thought that assembly was a type of programming language.
Re: I summarized my understanding of Linux systems
#24I don't understand what the boxes on this diagram are meant to represent. It feels like an elaborate mechanism to draw something wrong in the hopes people will correct it.
[flagged]
Re: I summarized my understanding of Linux systems
#25Earlier quoted context omitted.
Nor does mine. Userspace assembly runs directly on the CPU* executing in the unprivileged ring. When the userspace program makes a system call by calling a kernel entry function which is mapped into the process's address space by the dynamic loader, then part of that entry into kernelspace is to put the CPU into the privileged ring and kernel assembly then runs on the CPU. The process scheduler can stop execution to…
> execute assembly I always thought that assembly was a type of programming language.
It is. From my understanding, CPUs execute machine code. Assembly has to be passed through an assembler to get machine code, and that assembler can make other changes as well, so they are not always one to one. Written assembly will usually translate veryclosely to machine code, though.
Re: I summarized my understanding of Linux systems
#26I learned a lot about this from the book "The design of the Unix operating system" by Maurice J. Bach.¹ It's an old book and many details deviate from actual present-day Linux, but it nonetheless gives a great overview of the key components and ideas.
¹ https://books.google.de/books/about/The_Design_of_the_UNIX_O...
Re: I summarized my understanding of Linux systems
#27"The Linux Programming Interface" by Michael Kerrisk is one of the best technical resources I have found and used to understand Linux:
Description from the book's website:
"The Linux Programming Interface (TLPI) describes system programming on Linux and UNIX.
TLPI is both a guide and reference book for system programming:
If you are new to system programming, you can read TLPI linearly as an introductory guide: each chapter builds on concepts presented in earlier chapters, with forward references kept to a minimum. Most chapters conclude with a set of exercises intended to consolidate the reader's understanding of the topics covered in the chapter.
If you are an experienced system programmer, TLPI provides a comprehensive reference that you can consult for details of nearly the entire Linux and UNIX (i.e., POSIX) system programming interface. To support this use, the book is thoroughly cross referenced and has an extensive index."
Re: I summarized my understanding of Linux systems
#28Why a UML book is listed as a reference ?
Re: I summarized my understanding of Linux systems
#29Why a UML book is listed as a reference ?
[deleted]
Re: I summarized my understanding of Linux systems
#30My 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.
It doesn't directly access memory. The addresses in your userspace program are not the actual addresses of memory in the ram sticks - there is a table of mappings that the kernel sets up. When your process asks the kernel for memory, it says "i need 5KB, please put that at address XYZ". The kerenel goes and finds 5KB unused, probably at some other address ABC, and creates a mapping in the table that says XYZ translates to ABC. Then the kernel sets the MMU of the CPU to use the table for your process, and switches back to unpriveleged mode, letting your process run again. Your process in unpriveleged mode sends an instruction to write to the memory at XYZ, but the cpu will translate that instruction to ABC and write there instead.
VMs (well not emulated vms, but if you're doing an x86 vm on x86 or an arm vm on arm) do something similar - an inaccurate (but useful for the concept) way to think of it is that the cpu does 2 layers of MMU for user processes in a vm.
The kernel code isn't running directly when your program accesses memory, but it sets up the cpu so that the kernel still has control over your memory, and you only have access to what the kernel allows - its mediated by the kernel.