Greetings!
In the past few years, I have had the opportunity to study the source code of about three dozen operating systems to one degree or another. I probably won't even remember all of them. Basically, these were small libraries for microcontrollers, but "large" OSs also had to be viewed with varying degrees of immersion.
All this time, I also observed posts on various resources about "OS development", which basically boiled down to the output of "hello world" in QEMU, and complained that there was no need to confuse the OS and "a program that can run on bare metal" ... OS is not at all about working on hardware, it is, first of all, about synchronization and all that jazz.
One might argue that anyone interested in "academic" development should read books, not HOWTO posts on the Internet. On the other hand, books like the works of E. Tanenbaum also have shortcomings, which lead to the fact that the stream of posts mentioned above does not dry out. Tanenbaum's book (about MINIX) is still of a rather "high" level, and many questions that arise in practice are not considered there at all. And there is one more thing. Historically, the development of general-purpose operating systems and RTOS went in opposite directions: in UNIX-like operating systems, single-threaded processes first appeared, and only after a while the processes became multi-threaded; in the realm of RTOS it was the other way around, first there were “single-process” multithreaded systems, and only then there could be more than one process. There is an opinion that the second case is better for studying,because you can start with something simpler and complicate things gradually, and eventually come to the same thing. But I digress.
All this grumbling of mine was met by others and colleagues with phrases like “criticizing - suggest”, “do better”, “the pianist plays as he can”, “everyone can offend the artist”, etc. Therefore, one day patience ran out and I said ok, challenge accepted. And he sat down to write his own version of "the right way."
By the way, for the financial and moral support of this whole event, I would like to thank the Eremex company, as well as the colleagues who performed the feat of labor in the form of reading and editing the initial draft.
When the volume reached 250 pages, it became clear that it was necessary to stop in time. This work, in general, remained unfinished, but, nevertheless, I think, even in this form, the book illustrates the concept well and can be useful to those interested in the topic. According to reviews, it is rather difficult to read it, so if there are any suggestions on how to fix this, I would be grateful for them.
In my opinion, the OS is the answer to a set of problems that arise when it is necessary to organize the work of several independent tasks. Therefore, you need to start with a description of the problems and possible approaches to their solution, and not just say that it happened historically, let's discuss exactly how it happened. So the book is not that opposed to the classic works, but rather supplements them and offers a slightly different view of things from the side of embedded systems and RTOS.
I would like to discuss the issues that are faced not by the theorist studying the course of operating systems at the university, but by the programmer. Therefore, questions such as "why is synchronous context switching not a good idea in general?", "What qualitatively changes in the kernel when it is necessary to support isolated processes?" etc.
There is also the point of view that operating systems have yet to undergo an architectural and ideological transformation similar to that experienced by compilers due to the separation of the frontend and backend in the form of LLVM. At first, no effect was seen from this separation; the programmer used the compiler in the same way both before and after. But it was this separation that made possible the emergence of Rust and other languages, whose creators were able to immediately focus on the semantics of their language, and the backend was ready to use. Likewise, it would be desirable to divide the OS into several parts so that all this is written by different people as independent projects. FX-RTOS is
used to illustrate the principles described.as one of the possible approaches to this problem as well. Of course, in order to be able to describe some parts of the kernel without touching other parts, it must be written in such a way as to allow it. Although here I put the cart a little ahead of the horse, because at first the OS itself appeared, and then it became clear that its architecture is well suited to study the subject using its example, since you can increase the functionality in very small steps and enter all concepts gradually.
The sources mentioned above can be used to illustrate concepts up to and including chapter 6, then you can already smoothly move on to MINIX.
In order for everything not to look like quite a jump off the bat, I had to add the first two chapters, which are devoted to general concepts and hardware. Programmers can skip them without affecting understanding of the rest.
You can download the book for free without registration and SMS here .
Thank you all for your attention, critical reviews are welcome, but if they are more than two sentences in length, then it is better to write in private messages, because comments tend to grow and turn into a discussion tree of related issues, which is difficult and inconvenient to work with.
PS If the topic turns out to be interesting, I will write about FX-RTOS itself later.