51–60 of 88 posts
Earlier quoted context omitted.
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.
And Marshall Kirk McKusick wrote the latter, "The Design and Implementation of the FreeBSD Operating System"
Earlier quoted context omitted.
> 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.
Having to know structs is not really an issue - you also need to know text formats, JSON schemas, what not. 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 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.
open() read() write() close()
Such a theoretical linux-like or unix-like OS would assume quite literally that "everything is a file" -- including the ability to perform all other syscall/API calls/functions via special system files, probably located in /proc and/or /sys and/or other special directories, as other posters have previously alluded to...
Also, these 4 syscalls could theoretically be combined into a single syscall -- something like (I'll use a Pascal-like syntax here because it will read easier):
FileHandleOrResult = OpenOrReadOrWriteOrClose(FileHandle: Integer; Mode: Integer; pData: Pointer; pDataLen: Integer);
if Mode = 1 then open();
if Mode = 2 then read();
if Mode = 3 then write();
if Mode = 4 then close();
FileHandle is the handle for the file IF we have one; that's for read() write() and close() -- for open() it could be -1, or whatever...
Mode is the mode, as previously enumerated.
pData is a pointer to a pre-allocated data buffer, the data to read or write, or the full filename when opening...
(And of course, the OS could overwrite it with text strings of any error messages that occur... if errors should occur...)
pDataLen is the size of that buffer in bytes.
When the Mode is open(), pData contains a string of the path and file to open.
When Mode is read(), pData is read to, that is, overwritten.
When Mode is write(), pData is used to write from.
All in all, pretty simple, pretty straightforward...
A "one syscall Linux or Unix (or Linux-like or Unix-like) operating system", if you will... for simplicity and understanding!
(Andrew Tannenbaum would be pleased!)
Related: "One-instruction set computer" (OISC): https://en.wikipedia.org/wiki/One-instruction_set_computer
Earlier quoted context omitted.
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 translat…
I think the point of the diagram is that the abstractions or “API” that user space gets to use includes memory it can read and write directly, and a CPU to execute instructions. Of course in reality there only “appears to be” memory and a CPU, but that’s why it’s an abstraction. Just like there “appears to be” a filesystem for user space to use, when in reality there’s a block interface to a disk, or wherever you wan…
My instructions are executed directly on the cpu. My file reads and writes directly translated from a stream of bytes to block instructions by code in the kernel.
Memory is a wierd in-between place, or maybe a 3rd option, since the kernel has to run a bunch of code on my behalf for me to use memory, sort of like the filesystem thing, but I'm using the direct hardware units afterward, sort of like instructions.
Earlier quoted context omitted.
> 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.
Having to know structs is not really an issue - you also need to know text formats, JSON schemas, what not. 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.
It doesn’t matter which order the client sends {“a”: 1, “b”: 2 }, it’s one object with “a” and “b” regardless
A future simple linux-like (or unix-like) OS -- could theoretically be created with only 4 syscalls : open() read() write() close() Such a theoretical linux-like or unix-like OS would assume quite literally that "everything is a file" -- including the ability to perform all other syscall/API calls/functions via special system files , probably located in /proc and/or /sys and/or other special directories, as other pos…
My 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.
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...
Any diagram by ScotXW on Wikipedia is somewhere between misleading and completely wrong, and they're a constant pain on the Linux graphics community. If you're curious about the details in this case, ScotXW confuses EGL and OpenGL, the arrows aren't quite right, and the labels aren't quite right either (DRM is labeled "hardware-specific" but KMS isn't? The label for "hardware specific Userspace interface to hardware…