When learning system calls, the book mentions mechanisms and strategies, and is a design pattern that helps us understand the design of the operating system.
Unix/linux's interface design has a general motto of " providing a mechanism rather than a strategy ".
The differential treatment mechanism (mechanism) and policy are a major highlight of Unix design. Most programming problems can be cut into two parts: " What functions are required ( mechanisms )" and " How to implement these functions ( policies )". If the program can be implemented by separate parts of the mechanism and strategy, then the development of software is easier and easier to adapt to different needs.
Open source---Show us thousands of code behind that line of code, What kind of design ideas are there, and how have the Masters tried to think about them? In the face of a heap of code, sometimes it's easy to get lost in the entrances we've entered, and into the swamps of symbols, variables, and functions.
What is the nature of the operating system? Managers? Or a service provider? But ultimately, the operating system is a performer .
Execute user Program---so-called User Service, execution interrupt--- so-called peripheral services; called system calls--- so-called liberating programmers (let's say it serves the vast number of programmers, Because programmers are no longer dealing with complex hardware), executing kernel threads--- servicing the operating system itself. And all of this, the core of their execution, is simply the right time to have the CPU for which object (program, thread, interrupt service, lower half of the interrupt, system call). In other words, Unix/linux abstracts the execution mechanism of these objects:
The execution mechanism of the program---process ;
execution mechanism of kernel functions---thread;
The execution mechanism of interrupt service program---interrupt signal triggering,
interrupt the execution mechanism of the lower half---softirq, tasklet, Task Force;
system invoke execution mechanism---soft interrupt (int $0x80 trigger)
from a mechanism and a policy perspective, perhaps, You have an enlightened sense of the problems that have been puzzling.
If the mechanism is a framework, then the strategy is to populate the framework of a specific entity. The mechanism provides an open and relaxed environment, and strategy is the living individual that lives on in this environment. For example, we write a program that, after fork (), becomes the individual of a process . The various primitives that the operating system provides to us to create, execute, and end processes---fork (), exec (), and exit () are the mechanisms that govern various processes. The fate of the process we create does not affect the mechanism itself.
So perhaps we are disillusioned with the confusion of the principle. Anyone of us can call fork () to create n multiple processes at any time. Such a simple fork () shell, want to trace the trace, peel off the shell, you can see its essence. Fork () If there is any small bug that directly affects any of our programmers and any processes.
So, maybe we have some insight into the role of the developer. System analysts and designers have a heavy shoulder to do. In this regard, design patterns and other books, for those who are interested in moving from coding to design developers may be inspired.
Excerpt from teacher Chen's blog: http://www.lupaworld.com/home-space-uid-26540-do-blog-id-204505.html
Mechanism and strategy