Fushsia is a reconstruction of the Windows operating system.
Object's organization has been deeply carved into the bone marrow of Windows, and Fushsia, who also designed for the microkernel, inherited this design without evasion.
The development process of the operating system is that Windows and Linux constantly find their limitations from different angles, and try to solve these limitations from their respective perspectives. In this development process, countless remedies and new mechanisms have been invented, but both Windows and Linux are compatible with old things. The most important experience accumulated in the Windows evolution process is how to design the microkernel. The Linux evolution process has accumulated the containerization requirements such as stability and isolation lines. In this regard, Windows is also constantly following up. Android has designed a large operating system component outside the kernel, and the cooperation between Android and Linux is so ugly, because Android is equivalent to wanting to do something that a kernel should not do at the application layer.
Each operating system is undergoing painful iterations, each facing its own pain point. The world of Linux attaches great importance to permissions and isolation, but the mechanisms gradually added later, such as apparmor, selinux, and cgroup, are not so consistent with the original design. Since security has discovered the advantages of ACL, why do we still need the concept of user rights? Isolation resources with different memory can be grouped and isolated. Why do we need uniform fork inheritance? Windows is known for its graphics, and windows and gameplay are recognized advantages of Windows. How does his advantage shape? How to create a similar one? Simply speaking, it is because driving the closed source, but the deeper reason is still more complicated.
Android is like an experimental system. He hopes to achieve the advantages of Windows in terms of graphics (broadly speaking, hardware support), and at the same time envy the rich feature set of Linux. He knew from the beginning that he would not rely on Linux for a long time, otherwise the Java architecture would not be adopted. If I want to evaluate Android, it is that Android is more of an architectural level of DEMO, verifying the architectural design ideas of the operating system. As for the implementation, it is almost enough to support this architectural design. To verify this process, his kernel can only use Linux, there is no better choice. However, Google has always believed that Linux has done too many things that he should not do (many people think so). In fact, the root cause is that excessive open source agreements prevent others from making money.
Fushsia is a low-level replacement for Android. But this replacement is not on the code, but on the architectural level. Google seldom plays chess in the strategic direction. He hopes to advance in various fields while everyone is moving towards the same big goal as much as possible. This goal is an open source monopoly of Windows. In the entire open source world, Google hopes to eat all upstream and downstream. This approach requires that Google ’s fist-open source products in all sub-sectors, promote each other, learn from each other, help each other, and advance together.
The first choice is the microkernel or macrokernel. There is basically no dispute. As a toy between companies, decoupling is the first. To quickly industrialize and allow participants to make independent changes, the microkernel is almost the only option. Before the macro core was Linus, no one dared to think of success. To this day, no one can grasp how far this macro kernel can go. The macro core needs a dictator, he outlines leadership, and dictates. When you deviate, you can directly seal off your road. The entire Linux world, leaving Linus itself, no one has this prestige (imagine how the emperor's three sons ruled the country).
Between departments and companies, microkernels are more reasonable. The microkernel is a social kernel, and the macrokernel is a technical kernel. In terms of performance, the microkernel cannot beat the macrokernel anyway, because the macrokernel is equivalent to any subdivided change that requires integration testing. Any subdivision changes within the overall framework, including architectural style and even coding style.
So it is easy to think of the ideal operating system looks like Android design architecture + microkernel. This microkernel is just a direct reference to the successful experience of Windows. The design of Windows represents the highest level of current commercial operating systems. Any team without enduring success at the product level will not dare to abandon Windows in the design of the microkernel The design of the most is to learn first, and then find a way to surpass. Including Hongmeng now, the architecture of its microkernel must also be similar.
The typical microkernel architecture of Windows is Object design. The resources managed by the kernel are all objects one by one, and each object opened has a corresponding handle. It is also necessary to organize scheduling units such as process threads in the microkernel. This kind of architecture that has evolved along the way cannot be directly abandoned by a new system unless he wants to end like IBM 360. Security is attached to Object. The microkernel must be guaranteed to be included and can only be included, typically the privileged code of ring 3. In order to achieve the goal of running all ring3 code in the microkernel, many peripheral architectures must be designed into the kernel. For example, the process thread is a direct resource usage unit of the CPU. Is the scheduling of the user space or kernel space? This does not necessarily have a definite answer, but Fushsia chose to put it in the kernel, which means that the communication mechanism between processes must also be in the kernel. Windows has added a user-space scheduling interface, but that doesn't mean that the microkernel will let go. The operating system is a process that dynamically changes together in the development process of security, ease of use and conformity with social organization.
A very wonderful design under Windows is Event, and a similar design under Linux is signal. The two can be said to be completely different, but there are many similarities from the philosophical level. After in-depth thinking and practice, Google believes that the two can be combined. The three things of state, event, and signal can be abstracted into three models: Object, Signal, and Event. Each Object has 32 signal sets. Event is also an Object. It can be said that it is the simplest Object. There are only 32 signal sets in it. Therefore, the change of the object's signal set represents the change of their state. In other words, signals and states are coordinated into a concept, which is a set of signals held by an Object. The occurrence of signals can be the occurrence of events. Several different designs have been streamlined and linked by Google to extract their core essence. , Retaining their respective advantages, formed Fushsia's Object and Signal models.
Security under Windows is also an attribute of Object. Fushsia completely abandoned the concept of Linux user permissions at the microkernel level and changed to Object permissions for Windows. Even more radically, the entire virtualization is based on Object permissions (more precisely, HANDLE corresponding to Object). The biggest abstraction under Linux is that everything is a file, and the experience of the microkernel is that everything is an object, including the unit of process. Many Fushsia system calls have to pass into a process HANDLE, and this HANDLE determines whether the system call has permission to continue. The latest achievement of Windows is the heavy iteration of virtualization and sandbox technology, and Fushsia did it directly from the design level. Therefore, Fushsia is more like a reconstruction of a Windows system without burden, retaining most of the advantages of Windows.
Fushsia has different ideas in many places. For example, Windows has been criticized for writing inter-process kernels as a cradle of many security issues. However, transferring HANDLE between processes is a very useful resource transfer function under Windows. In Linux, an opened resource wants to be transferred to another process. In the early days, there was no way except for fork. SCM technology appeared later, which was to directly transfer fd through Unix Domain Socket. Because you can't default the environment that needs to pass resources are all parent-child process relationships. A big design problem with Linux is that it depends too much on the parent-child relationship. The problem with Windows is that it does not depend on the parent-child relationship too much, resulting in a lack of effective organization between processes. Recent versions of Windows have paid much attention to the organization of inter-process relationships, and more or less introduced the process relationship tree model under Linux. In the process of getting closer, both parties have gradually violated the original design. Causes the entire operating system to look unharmonious. This problem is deliberately amplified by Google in the Android system. Because the Android system relies heavily on Binder, Binder is a design that attempts to allow various processes to easily communicate and exchange resources. This design is difficult for Linux. The requirements for Linux are a bit too intense. Linux has always been a very important development direction for resource process isolation, and Android does the opposite, requiring the door between processes to be opened. Reading Binder's code makes it easy to know how difficult this system is. On the contrary, Binder is very easy to implement on Windows. LPC is so efficient. You can easily write your own HANDLE into the memory of another process between processes. The transfer of resources is almost free of cost. But writing directly to the kernel of the opposite process adds complexity to permissions and concurrency. Therefore, since Fushsia is the landing of the Android architecture, it naturally relies heavily on this feature. So Fushsia directly put the idea of Channel successfully implemented in Golang in Fushsia. To pass HANDLE, you only need to put HANDLE into the Channel. The original process automatically loses the resource, and the process opposite the Channel automatically obtains the resource.
There is a problem here, that is, the kernel block itself is also a resource, and HANDLE is also possible. This philosophy is almost not reflected in Linux. Android has designed the ashmem very hard in order to implement his architecture. It uses the memory file system to stiffly design the kernel block with handle. The underlying memory management of Windows is with HANDLE, called Section, a Section is a 64KB block. However, when Windows was exposed to the upper layer, it still did not choose to directly use the section for users, but encapsulated it. But in the microkernel is the way of section and its corresponding HANDLE. This method has been proved to be able to manage memory blocks and file mapping at the same time, and it can also provide a higher-level memory allocation mechanism. For Android's desire for HANDLE resource transfer, there is no reason not to learn the Windows Section mechanism. Fushsia is farther away than Windows, and does not directly use the Windows section, but creatively designed the pager, VMO, and VMAR. Also based on objects, continuous memory and pages are more flexible to abstract objects, overcoming the problem of granularity fixed under Windows (default 64KB). It is precisely because of more systematic objectification that no strategy attributes are added to the entire design, so the strategy can be raised beyond the microkernel. In other words, the service part of the operating system should be responsible for the entire memory management, but the granularity of the memory corresponds to the hardware Object in the kernel. This is another huge improvement for memory problems under Windows.
The organization of tasks under Windows adopts four dimensions: job, process, thread and fiber. This is also a complete set of session groups, process groups, threads corresponding to kernel processes, etc. that seem to be very awkward. Fushsia is also enhanced on the basis of Windows. The process is organized into jobs, and there are threads under the process.
Another impressive design under Windows is the Completion Port. When a large number of events occur, Completion Port abstracts it as sending a packet message to a HANDLE. Compared to Linux, similar things use epoll, ppoll and other event collection mechanisms, Completion Port is very clean in design. The same idea was directly adopted by Fushsia, and "localized" was implemented.
In the matter of locking, switching from Windows to Linux after working for a long time in the Linux environment will obviously feel that the design of Windows is very poor. As an operating system with the largest market share on the server side, Linux handles concurrency issues very well. This refers to the technical level, not the architectural level. One of the biggest advantages is that Linux abstracts all lock implementations into a dependency on futex system calls. The actual meaning of Futex has nothing to do with the lock, just a mechanism to wait for the condition and wake up the corresponding thread, which is a simple thread synchronization mechanism. Linux succeeded in making all kinds of locks rely on a simple synchronization mechanism to achieve their goals. Such a good abstract formal Fushsia to learn and learn from. Under Windows, the process of using Mutex, CriticalSection, RWLOCK, etc., is cross-process or in-process. Different performances are all black boxes and independent. This is obviously not what a microkernel should be. But whether the Windows microkernel provides a futex-like mechanism to support the implementation of upper-layer locks, this is not clear to me, I have not looked at it in reverse. Anyway, I don't like the lock design under Windows very much.
In terms of scheduling algorithms, the operating system industry is gradually transitioning to Fair Scheduling, especially Linux. Fushsia cannot refer to Windows, because no one knows the details, and the long-term engineering practice of Linux has proved feasible. You know, the early Linux scheduling was scolded at every turn. It is not easy to get the experience accumulated now.
Isolation is a problem that both Windows and Linux are facing. The server first initiates a heavy demand for isolation. The degree of demand can be described as revolutionary. For a time, Linux virtualization technology sprung up and flourished. Because Linux supported this thing a few years before Windows. It all came down to a productive idea of Linux, a LXC virtualization technology that was once considered meaningless by chance. You can say a lot of advantages of Linux development virtualization, but without the LXC as a foregone technology, it is likely that the first Docker did not have the courage to release, and there will be no spring afterwards. Windows has been catching up in recent years, trying to catch up with and surpass the advantages of Linux in virtualization. At the same time, with its strong demand for isolation in UWP technology, Windows has created its own isolation and tried to erode Linux. No effort has been spared in the development of WSL technology. Fushsia sees the power of virtualization, and Android ’s experience has told Google that not only the server but also the client has stronger requirements for isolation, because Fushsia ’s isolation is a deep-seated design that reflects the entire The isolation refactoring of the architecture. Typically, there is no file system at the operating system level that we are familiar with. There is no root directory, and each process can only see its own private directory. Fork is completely removed, even Windows has to be in awe of it. Windows still allows Object to inherit between process creations, so Windows is a selective support for the concept of fork, but it is far less than the full inheritance of Linux. The child process under Linux has to subtract the parent process. Some changes will cause the subtraction to not be reduced in place often, and there will be many security problems. Fork's design is not designed for isolation. On the contrary, he completely shares data and even logical channels. It is a complete anti-isolation design. Fushsia has completely redesigned this, and the new process is a dry and quiet container. New technology like Windows UWP, complete sandbox, eliminate the possibility of escape from the bottom. Windows would also be very envious of Fushsia's ability to directly carry out a very radical pure sandbox design without historical baggage.
Other similar fields include TLS, DMA, logging, interrupts, etc. Both are redesigning to find an optimal balance of usage and architecture with a series of needs in the process of using Linux, Windows, and Android and their crappy ways of satisfying. It can be said that Fushsia's Zircon microkernel is an architectural design that best matches all current scenario applications. The number of system calls is very small, Linux has been streamlined, but the historical burden is serious, and the Windows microkernel makes it impossible to distinguish the level of system calls, resulting in a very chaotic API. Zircon made a good start, providing a set of system calls, but handed over a lot of work to the service. Service is also a very good concept on Windows, and it is an essential matching component of the microkernel. Android's architecture has designed a large number of services, such as SurfaceFlinger, Zygo, etc., and there is a lack of effective expression of services under Linux. Because many of the logical units of the macro kernel that should be services are made into kernel threads, but they are not complete. Linux's macro kernel does a lot of services on its own, but it is not complete enough, and it is impossible to complete. It still needs user space services to complete. For example, systemd tries to organize Linux services in a unified manner, but various targets and startup processes, service management, and dependencies make the entire system extremely complicated. My personal design for the service side of Linux has always been scornful, because there has always been a comparison of Windows. However, the Windows service cannot be said to be no problem. Many rogue software uses the service to do a lot of things that affect the experience. Apple controls this very well. It can be said that Windows is a system with excellent design and implementation at the architectural level, but the response speed is too slow, which is far less adaptable than Linux. And Microsoft's own control of this system is not strong, resulting in users sometimes being controlled by rogue software. And Apple is too strong, everyone feels controlled by Apple. Android's design is a balance, isolation, and control are just right. It can be strongly controlled by an OEM, or it can be completely uncontrolled. It is a very flexible social design. In contrast, the enterprise version of Windows similar concepts, the organization can control very limited things, and basically the application is only internal to the company. Similar organization delivery capabilities, Microsoft is reluctant to give anyone, so over-open. However, it has recently tightened. Apple is also reluctant to give it to anyone, so
What Google envisions is a big social architecture that can stretch out, open source, make money, make money for itself, and make money for others. Google knows very well the power of the open source model and the powerful influence of the closed-source world. More social attributes are the most important factors that make Google stand out. Because he "grounded".
At the driver level, Zircon has even opened system calls for user program interrupt handling. The kernel level is equivalent to direct application layer delegation to the driver, but not to the application, but to the DDK. s frame. One of the biggest benefits Android brings to Google is an in-depth understanding of the driving world. DDK is such a design that extracts sublimation and then re-landing. I always think that Windows is the object of Zircon's architecture learning, and Linux is a good object for verifying algorithm logic, and it is also a good textbook. Android is an attempt, a verification of architectural design and social learning accumulation. The goal is the final unified design. The core IPC calling interface of the entire Fushsia is FIDL (or "Fuchsia Interface Definition Language" ), This descriptive IPC expression is exactly the same as binder. The concepts of Component, capbility and manifestation are also the development mode of Android verification (capbility is unclear whether there is any reference to Linux). With the gradual promotion of Flutter, the effectiveness of Fushsia's model is being verified step by step by Android and Windows. The point of the file system is that Linux and Windows are not good. Fushsia has its own design, but I ca n’t comment on whether it is good enough. I'm afraid we have to wait for the actual landing to know. IO this point, Windows has countless failures, Linux elevator and cache design is not good, Fushsia can certainly do better, after all, redesign, complete reference. But I think it will be better to see later. For example, the ashmem used by Android has the same function to simulate embarrassment under Windows, and it also depends on the existing tmp file system under Linux. Fushsia directly appeared MemFS this tailored file system. Volume Manager is very good on Linux, but it is terrible on Windows. Fushsia has also been redesigned. The mounting concept of Mount is a basic function on Linux. This design is so excellent. Now Windows is also learning. When Windows enters the field of virtualization, it finds it necessary to mount a file system to a directory on another disk. Sexuality also produces the corresponding technology. This kind of design, which was invented by a system (and cannot be said to be invented by Linux) and adopted by Windows, will naturally not be missed by Fushsia. The implementation of the network file system in Linux and Windows is not good, but each has its own advantages. The application of the 9P protocol in WSL has been noticed by Google, but the landing of 9P has become a high-latency paper talk. Fushsia's similar development route uses the descriptive interface and the concept of establishing connections that both Windows and Android now use for IO design, and the effect remains to be evaluated. I am very worried about the mistake of 9P. There are a lot of idealist engineers in Windows and Google who pay too much attention to the completeness of the architecture, and have already made many "magic" works. The high level of its architecture can often hide the ugliness of implementation. But at the performance level, it cannot be covered. The performance process, in most cases, is a destructive process that constantly destroys the beautiful architecture. I do performance. I really understand this sentence.
The display is one of the biggest failures in the Linux field. Fortunately, there is some recovery from Android, but it is also a huge effort. The proud display of Windows is the result of a deep customization collaboration from Directx to drivers, and from software to hardware. This usually has a very big business motivation. Linux itself does not have this kind of motivation, and mobile phones do. Fushsia naturally attaches great importance to this field of life and death. The large amount of rendering experience accumulated in Android makes Fushsia fully aware of the independence of the rendering part. Android's isolation of SurfaceFlinger's design and game ontology rendering makes traditional single-threaded rendering very cumbersome. This architecture is naturally a product of the transition period, and Vulkan and Directx12 themselves are abandonment of this architecture. The rendering subsystem itself is responsible for task scheduling and memory management. This is a problem that has been recognized by modern rendering architectures. From the architectural level or operating system too much intervention in the rendering process, the harm is far greater than the benefit, because rendering is a performance-first area, no matter how beautiful your architecture, there is a strong motivation to give up in front of performance. With the highly strategic development of command queue caching, task scheduling, and memory management such as Vulkan and Directx12, Fushsia, as a new era operating system, consciously made concessions to rendering. Let the rendering subsystem be able to undertake more and more autonomous work. Not only that, graphics computing technologies such as Direct Compute have made the CPU scheduling level aware of the deficiencies in computing, and computing will also be foreseen in the future by the rendering pipeline. The battle between the CPU itself and the GPU saw the first concession of control at the software level.
Fushsia is a new era operating system, his birth is almost based on the painful foundation of Windows and Linux. What is changing is the need. Whether the architecture can better adapt to the rapidly changing needs is an important guarantee for the long-term development of the operating system. Now that Linux and Windows are both old-fashioned, they are still insisting on updating, constantly innovating and breaking through time to meet the needs of society. Windows and Linux are like two brothers. When the society needs the operating system, when Linux can't bear it, Linux is the top. Where Linux can't stand, the top is Windows. In the process of iteration, both parties finally divided the domain layer gradually. Linux is more suitable for the server side, and Windows is more suitable for the client side. It is better to say that Linux has chosen to give priority to satisfying the server side in the process of meeting the demand, and even the embedded is almost lost. In the process of choosing to meet the demand, Windows chose to give priority to satisfy the client. Both looked at each other's territory and refused to give up hope.
Fushsia was built on the development and positioning of two operating systems. The two directors of Bocai carried out a redesign on the shoulders of giants. This time, it's not DEMO, nor java. This time, Google's goal is the ultimate. He wanted to end the operating system debate here. I believe that Hongmeng ’s design cannot go beyond Fushsia. If every day roars out of the era, it is obviously not the person of this era. No one can survive beyond the times. The evolution of technology must be based on existing technologies at the philosophical level, design level, and innovation level. If Fushsia is an innovation for Windows and Linux, I believe Hongmeng should innovate on the basis of Fushsia's philosophy. Because there is no reason for Google to sum up, the high-quality property obtained through experiments and discoveries cannot be inherited. It is a reasonable choice to modify on this basis. The different architectures that came out of nowhere were completely rewritten. I personally do n’t approve of it or do n’t believe it. Wait for him to open source.
