Could someone suggest hands-on resources for learning about kernels, such as a book or series on writing your own kernel? I'd like to gain a deeper understanding of their workings and I think hands-on or project based learning would help.
I summarized my understanding of Linux systems
81–88 of 88 posts
Re: I summarized my understanding of Linux systems
#82Could someone suggest hands-on resources for learning about kernels, such as a book or series on writing your own kernel? I'd like to gain a deeper understanding of their workings and I think hands-on or project based learning would help.
osdev would help. It's not a book but a website.
Re: I summarized my understanding of Linux systems
#83Could someone suggest hands-on resources for learning about kernels, such as a book or series on writing your own kernel? I'd like to gain a deeper understanding of their workings and I think hands-on or project based learning would help.
osdev would help. It's not a book but a website.
Taking a look, it has a ton of resources. Thanks!
Re: I summarized my understanding of Linux systems
#84Nice! 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…
I remember when Wikipedia first became popular, there were a lot of warnings about how you couldn't trust the information because "anyone could edit it". I feel like, at least to my level of understanding whatever I'm reading about, it's been sufficient and I've never identified something wrong/inaccurate (except for perhaps recent news or recently debated political topics). This is the first time that I've seen that downside of Wikipedia, as I use it for understanding things like this and never would've known that the diagram I was learning from was wrong. Thanks for commenting this, it's good to know
Re: I summarized my understanding of Linux systems
#85My 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…
Do you happen to have any other suggestions about reading?
I am currently reading "Asynchronous Programming in Rust: Learn asynchronous programming by building working examples of futures, green threads, and runtimes" and there is vague talk about how cpus process things, but it really would like to know more. I am even curious about what is actually happening in hardware. It seems hard to determine where to start.
I don't have formal education in this field unfortunately.
Re: I summarized my understanding of Linux systems
#86Earlier quoted context omitted.
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…
I remember when Wikipedia first became popular, there were a lot of warnings about how you couldn't trust the information because "anyone could edit it". I feel like, at least to my level of understanding whatever I'm reading about, it's been sufficient and I've never identified something wrong/inaccurate (except for perhaps recent news or recently debated political topics). This is the first time that I've seen that…
The specific article is: https://en.wikipedia.org/wiki/Free_and_open-source_graphics_.... I can understand the "multiple issues" section here, this seems super-technical in a certain way in comparison to what I usually see on Wikipedia (although wk does get very technical on very specific isolated things in e.g. math, usually non-theory tech pages are a summary), but I still found it motivating to dig into Linux. I wouldn't be surprised if it was removed.
I love wikipedia and I read to procrastinate by reading the articles for everything I am interested in so I have found quite a lot of factually incorrect information or statements of fact which are really philosophical opinions. However usually these problems coexist with a certain change in writing style (loss of formatting, grammatical errors, random capitalizations, change of tone, etc.). I find I haven't found many problems with content written in the usual "wikipedia" style, so I assume the hardcore wk editors who enforce this style care a lot about factual accuracy. However I don't read enough outside of wikipedia so I wouldn't know if everything is correct...
(actually now that I think about, maybe I am more likely to agree with things in the wikipedia style. But I think the style errors and factual errors are at least a bit correlated.)
Re: I summarized my understanding of Linux systems
#87Earlier quoted context omitted.
CPU is pre-configured by OS as well. So IMO it's the same as memory. May be it would be more appropriate to say that userspace program accesses directly some parts of CPU and RAM. With modern computers, AFAIK even OS does not have absolutely full control over CPU.
But they don't directly access memory. They access an address that may be translatable by the mmu to a physical location in ram. They may also write to an address that the kernel hasn't allocated a page for yet, but that the kernel has agreed to map into the process' memory. In this case the kernel handles the trap and maps a page of actual ram (etc) and then the process continues forward progress.
That's just the way CPU works. It has nothing to do with kernel or userspace. Kernel code will behave identically.
Re: I summarized my understanding of Linux systems
#88Earlier quoted context omitted.
Everything is a descriptor. When I'm opening a TCP connection, there's no file, so calling it a file descriptor feels wrong. And at that point, the whole "everything is" turns into nonsense, because yes, everything is a pointer to something, so what.
There are named files (which have a file path) and anonymous files (which do not). You can see these in /proc/$PID/fd/$FD if you're curious - when the link doesn't start with '/', it's anonymous. Even process memory is just an anonymous file on Linux, and arguably a cleaner one as it operates on proper fds, instead of plan9 where a string "class name" (not a path) is used to access the magical '#g' filesystem. The di…
I've only briefly looked at plan9 here and there over the years but you seem to have a pretty good handle on it and maybe could indulge me. Your comment raised a question for me that I hadn't considered before.
If I've got a Plan9 system mounted over, say, NFS, would this all mean that (ignoring permissions) I could effectively open a TCP connection from that remote machine by writing appropriate information to a file on the NFS share? It would be pretty inefficient I suspect, tunnelling TCP over NFS, but it seems like there could be an incredible amount of cool hacks that might Just Work as a side-effect of them going all-in on "everything is a file".