When the process changes,
cr3 change to point to the page table of the new current process.A simple and naive solution would be to completely invalidate the TLB whenever the
cr3 changes.However, this is would not be very efficient, because it often happens that we switch back to process 1 before process 2 has completely used up the entire TLB cache entries.
The solution for this is to use so called "Address Space Identifiers" (ASID) as mentioned in sources such as:
Basically, the OS assigns a different ASID for each process, and then TLB entries are automatically also tagged with that ASID. This way when the process makes an access, the TLB can determine if a hit is actually for the current process, or if it is an old address coincidence with another process.
For each process, the virtual address space looks like this:
------------------ 2^32 - 1
Stack (grows down)
v v v v v v v v v
------------------
(unmapped)
------------------ Maximum stack size.
(unmapped)
-------------------
mmap
-------------------
(unmapped)
-------------------
^^^^^^^^^^^^^^^^^^^
brk (grows up)
-------------------
BSS
-------------------
Data
-------------------
Text
-------------------
------------------- 0The kernel maintains a list of pages that belong to each process, and synchronizes that with the paging.
If the program accesses memory that does not belong to it, the kernel handles a page-fault, and decides what to do:
When an ELF file is loaded by the kernel to start a program with the
exec system call, the kernel automatically registers text, data, BSS and stack for the program.The
brk and mmap areas can be modified by request of the program through the brk and mmap system calls. But the kernel can also deny the program those areas if there is not enough memory.brk and mmap can be used to implement malloc, or the so called "heap".mmap is also used to load dynamically loaded libraries into the program's memory so that it can access and run it.Stack allocation: stackoverflow.com/questions/17671423/stack-allocation-for-process
Calculating exact addresses Things are complicated by:
- Address Space Layout Randomization.
- the fact that environment variables, CLI arguments, and some ELF header data take up initial stack space: unix.stackexchange.com/questions/145557/how-does-stack-allocation-work-in-linux/239323#239323
Why the text does not start at 0: stackoverflow.com/questions/14795164/why-do-linux-program-text-sections-start-at-0x0804800-and-stack-tops-start-at-0
Information about ARM paging can be found at: cirosantilli.com/linux-kernel-module-cheat#arm-paging
However, many, many, many terrible horrors come with it:
- it hasn't made the move to desktop for too many years. It could destroy Microsoft Windows and replace it with open source, but they just won't budge towards an unified mobile/desktop setup.
- vendors litter it with uninstallable bloatware that should be illegal. European Union to the rescue!!! www.cnbc.com/2020/12/15/digital-markets-act-eus-new-rules-on-big-tech.html
- vendors lock down devices so it is very hard to get sudo, let alone to modify their images!
- there isn't enough hardware standardization for open source distros to thrive like on desktop
- code drops mean that "master" is useless and trying to contribute from outside vendors' closed walls is a waste of time: stackoverflow.com/questions/1809774/how-to-compile-the-android-aosp-kernel-and-test-it-with-the-android-emulator/48310014#48310014
- if you ever go below the Java API, e.g. to C++ or AOSP build, everything is horrendous and undocumented
- Google doesn't care about the CLI, even the hello world requires creating infinite out-of-control boilerplate from a GUI: stackoverflow.com/questions/20801042/how-to-create-android-project-with-gradle-from-command-line/46994747#46994747
- the boot is uber bloated and takes forever in cycle simulators
Open source driver/hardware interface specification??? E.g. on Ubuntu, a large part of the nastiest UI breaking bugs Ciro Santilli encountered over the years have been GPU related. Do you think that is a coincidence??? E.g. ubuntu 21.10 does not wake up from suspend.
How Nvidia Won Graphics Cards by Asianometry (2021)
Source. - Doom was the first killer app of personal computer 3D graphics! As opposed to professional rendering e.g. for CAD as was supported by Silicon Graphics
- youtu.be/TRZqE6H-dww?t=694 they bet on Direct3D
- youtu.be/TRZqE6H-dww?t=749 they wrote their own drivers. At the time, most drivers were written by the computer manufacturers. That's insane!
Heinrich Hertz's main initial experiment used a spark-gap transmitter. It is not something that transmits recorded sounds like voice: it only transmits noisy beeps. And as such was used for wireless telegraphy.
- a piezo igniter from a barbequeue lighter
- a more powerful home-made transformer
Hertz and Radio waves Explained by PhysicsHigh (2016)
Source. Simple schematics showing the basics of the experiments. No choice of components rationale. Pinned article: Introduction to the OurBigBook Project
Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
Intro to OurBigBook
. Source. We have two killer features:
- topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculusArticles of different users are sorted by upvote within each article page. This feature is a bit like:
- a Wikipedia where each user can have their own version of each article
- a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
Figure 1. Screenshot of the "Derivative" topic page. View it live at: ourbigbook.com/go/topic/derivativeVideo 2. OurBigBook Web topics demo. Source. - local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
- to OurBigBook.com to get awesome multi-user features like topics and likes
- as HTML files to a static website, which you can host yourself for free on many external providers like GitHub Pages, and remain in full control
Figure 3. Visual Studio Code extension installation.
Figure 4. Visual Studio Code extension tree navigation.
Figure 5. Web editor. You can also edit articles on the Web editor without installing anything locally.Video 3. Edit locally and publish demo. Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.Video 4. OurBigBook Visual Studio Code extension editing and navigation demo. Source. 
- Infinitely deep tables of contents:
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact