- Each device driver should run as an independent, user-mode process.
- Software can last a long time and should be designed accordingly.
- It is very difficult to get people to accept new and disruptive ideas.
- Make the (micro) kernel as small as possible, since kernel failures are fatal.
- Be careful what you put on the Internet; it might come back to haunt you decades later.
- All developers should try to use their own systems as early as feasible so they can see what users will experience.
- Lesson: Eat your own dog food.
- Lesson: Do not trust documentation blindly; it could be wrong.
- Without MINIX, it is inconceivable there would have been a Linux since Linux Torvalds learned about operating systems by studying the MINIX source code in minute detail and using it as a base to write Linux.
- Lesson: Listen to your students; they may know more than you.
- Lesson: Nathan Myhrvold's Law is true: Software is a gas. It expands to fill its container.
- With some discipline, developers can try to break this "law" but have to try really hard. The default is "more bloat".
- Lesson: No matter how desirable your product is, you need a way to market or distribute it.
- Lesson: Size matters.
- Lesson: Try to make your design be appropriate for hardware likely to appear in the future.
- Lesson: By not relying on idiosyncratic features of the hardware, one makes porting to new platforms much easier.
- Lesson: As with software, hardware can contain bugs.
- A hardware "feature" can sometimes be viewed as a hardware bug.
- Lesson: When someone hands you a lemon, make lemonade.
- Lesson: The Internet is like an elephant; it never forgets.
- It turns out performance is more important to some people than I had expected.
- Also worth noting is in the world of embedded computing, where reliability often trumps performance, microkernels dominate.
- The L4 microkernel runs on the radio chip inside more than one billion cellphones worldwide and also on the security processor inside recent iOS devices like the iPhone 6.
- L4 is so small, a version of it consisting of approximately 9,000 lines of C was formally proven correct against its specification, something unthinkable for multimillion-line monolithic systems.
- Nevertheless, microkernels remain controversial for historical reasons and to some extent due to somewhat lower performance.
- Lesson: Do not assume today's hardware will be dominant forever.
- Lesson: When standards exist (such as ANSI Standard C) stick to them.
- Lesson: If you are running one of the biggest corporations in the world and a tiny startup appears in an area you care about but know almost nothing about, ask the owners how much they want for the company and write them a check.
- Lesson: Even after you have adopted a strategy, you should nevertheless reexamine it from time to time.
- Lesson: Working on something important can get you research funding, even if it is outside the mainstream.
- In the MINIX 1 and MINIX 2 designs, device drivers were treated and scheduled as independent processes but lived in the microkernel's (virtual) address space.
- Lesson: Try for an early success of some kind; it builds up everyone's morale.
- Lesson: Each device driver should run as an unprivileged, independent user-mode process.
- Lesson: Keep focused on your real goal.
- Do not be distracted when something seemingly nice pops up but is actually a hindrance.
- Lesson: If V3 of your product differs from V2 in a really major way, give it a totally new name.
- Lesson: Doing PhD research and developing a software product at the same time are very difficult to combine.
- Synchronous communication was there from the start and is very simple. It also conflicts with the goal of reliability. If a client process, C, sends a message to a server process, S, and C crashes or gets stuck in an infinite loop without listening for the response, the server hands because it is unable to send its reply. This problem is inherent in synchronous communication.
- Lesson: Einstein was right: Things should be as simple as possible but not simpler.
- What Einstein meant is everyone should strive for simplicity and make sure their solution is comprehensive enough to do the job but no more. This has been a guiding principle for MINIX from the start. It is unfortunately absent in far too much modern bloated software.
- Lesson: If you want people to use your product, it has to do something useful.
- Lesson: If marketing the product according to plan A does not work, invent plan B.
- The idea of a small microkernel with user-level system components protected from each other by the hardware MMU is probably still the best way to aim for highly reliable, self-healing system because this design keeps problems in one component from spreading to other.s
- Nevertheless, having most of the operating system run as user-mode processes is disruptive, and it takes time for disruptive ideas to take hold.
- Lesson: It is very difficult to change entrenched ways of doing things.
- Furthermore, in due course, computers will have so much computing power, efficiency will not mater so much.
- My initial decision back in 1984 to have fixed-size messages throughout the system and avoid dynamic memory allocation (such as malloc) and a heap in the kernel has not been a problem and avoids problems that occur with dynamic storage management (such as memory leaks and buffer overruns).
- Another thing that worked will in MINIX is the event-drive model. Each driver and server has a loop consisting of: get_request(); process_request(); send_reply();. This design makes them easy to test and debug in isolation.
- The structure of the system as a collection of servers makes live update much simpler than in traditional designs, since it is possible to do a live update on, say, the memory manager, without affecting the other (isolated) components because they are in different address spaces.
- In systems that pass pointers between subsystems within the kernel, live updating one piece without updating all of them is very difficult.
20170918
Lessons Learned from 30 Years of MINIX by Andrew S. Tanenbaum
Lessons Learned from 30 Years of MINIX
Labels:
compsci
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment