In the past few years, I have been able to one degree or another to study the sources of about three dozen operating systems. All of them, I probably will not even remember. These were mostly small libraries for microcontrollers, but the “large” OSs also had to be viewed with varying degrees of immersion.

All this time, I also observed posts on “OS development” on various resources, which basically boiled down to the conclusion 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 about working on hardware, it is, first of all, about synchronization and all that jazz.

One can argue that anyone who is 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 run out. The book of Tanenbaum (about MINIX) is still of a rather "high" level and many of the questions that arise in practice are not considered there at all. And there is one more thing. The development of general purpose OSs and RTOSs historically went in opposite directions: in UNIX-like OSs, single-threaded processes first appeared, and only after a while the processes became multi-threaded; in the field of RTOS, it was the other way around, at first “single-process” multi-threaded systems appeared, and only then there could be more than one process. It is believed that it is better to study just the second case, because you can start with a simpler one and complicate it gradually, but in the end come to the same thing. But I got distracted.

All this grumbling of mine was met by associates and colleagues with phrases like “criticizing - offer”, “do better”, “pianist plays as best he can,” “everyone can offend the artist,” etc. So one day, patience snapped and I said ok, challenge accepted. And he sat down to write his own version of "how to."

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 labor feat in the form of reading and editing the initial draft.

When the volume reached 250 pages, it became clear that we must stop on time. This work, in general, remained unfinished, but, nevertheless, I think that even in this form the book illustrates the concept well and may be useful to those interested in the topic. According to reviews, reading it is quite difficult, so if there are any suggestions on how this could be fixed, I would be grateful for them.

In my opinion, the OS is the answer to the totality 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 solving them, and not just say that historically this happened, let's discuss how it happened. So the book is not something that is opposed to classical works, but rather complements them and offers a slightly different view of things from the side of embedded systems and RTOS.

I wanted to discuss those issues that are not facing the theorist studying the course of operating systems at the university, but the programmer. Therefore, questions like “why synchronous context switching is generally not a good idea?”, “What changes qualitatively in the kernel if necessary to support isolated processes?” Are discussed etc.

There is also the point of view that operating systems have yet to go through an architectural and worldview 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 visible from this separation; the programmer used the compiler in the same way before and after. But it was this division that made possible the emergence of Rust and other languages, whose creators were able to immediately focus on the semantics of their language, and use the backend ready. It would also be desirable to divide the OS into several parts in such a way 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, including this problem. Of course, in order to be able to describe some parts of the kernel without touching the other parts, it must be written in such a way as to allow this. 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 it is possible to increase functionality in very small steps and introduce all concepts gradually.

The sources mentioned above can be used to illustrate concepts up to chapter 6, inclusive, then you can already move smoothly to MINIX.

In order for everything not to look like a really jump right off the bat, I had to add the first two chapters, which are devoted to general concepts and hardware. Programmers can skip them without consequences for understanding 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 larger than two sentences in volume, 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.

P.S. If the topic is interesting, I will write about FX-RTOS later.