31–40 of 88 posts
I 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...
I 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...
The only use I've had of this kind of documentation is that the process of writing it, made me understand it better. Basically write-only documentation.
I would call myself a Linux expert, and while I can kinda see what you mean with this diagram, it would not have been useful to me back before I was an expert.
Earlier 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.
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
Whichever superior depends on your use case and needs. Plan9's approach is very powerful whenever you need anything distributed, and makes lots of boilerplate to achieve that basically unnecessary. Linux nowadays is flexible for both approaches (in theory, the ecosystem might not be there), and I'm glad user namespaces are a thing.
> There's some ideological benefits, but plan9 creates a mess of implicit text protocols, ugly string handling, syscall storms and memory inefficiencies. On the other hand, linux ioctl and syscalls have infinite binary structs you need to know (and cannot let the compiler reorder fields in), which then doesn't make cross-platform development any easier.
Re-ordering of structs is always forbidden with the binary format being strictly specified, so there's nothing to worry about there. Can't exactly shuffle bytes in a text format either, and plan9 control strings tend to have positional arguments.
The current structs do leave something to be desired though.
I 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...
This is one of my favorite books. A true classic. There are follow-ups in that style for Linux and FreeBSD as well. I think Robert Love wrote the former.
Earlier 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.
https://www.youtube.com/watch?v=oO8_2JJV0B4
In short, assembly for a given CPU is very nearly one-to-one with the machine language for that CPU. It's not correct to conflate the two, but close enough when speaking informally.
SUN RPC for NFS, yellow pages,...
Whenever I've made notes like this, it's never been useful to my future self nor to anyone else. The only use I've had of this kind of documentation is that the process of writing it, made me understand it better. Basically write-only documentation. I would call myself a Linux expert, and while I can kinda see what you mean with this diagram, it would not have been useful to me back before I was an expert.