0.1 What's Your Goal & Plan?

 

[Home]  [Top]   [Next]


0.1.1 Overview 

当你雄心勃勃的准备开始做一个OS之前,你是否十分清楚你将面临着什么?——你做OS的目的是什么?你要做一个什么样的OS?你打算使用什么开发工具和开发环境?你准备使用多长时间来做这件事情?等等等等。

两年前,由于我在Minix邮件讨论组比较活跃,一个朋友(当时我们完全陌生)给我发来一封Email,问我是否有兴趣和他一块儿做一个面向对象的OS,我当时给他回了一封邮件,邮件中问了他几个问题,邮件原文如下:

你好!
    我已经收到了你的关于面向对象的操作系统设计的想法,由于我对这方面的资料了解甚少,所以我无法马上给你任何有关于它的任何建议,不过我觉得这个想法确实是一个比较不错的想法。
    关于这项工作的意义和价值你已经论述的很清楚,但在做它之前,你是否考虑过以下几个问题:
    1)你是否对面向对象的操作系统的几个特性有了充分的理解和认识,并且对如何实现它有了一个比较成熟的想法(关于面向对象操作系统的几个特性的实现方法)?
    2)你最多有多长的时间可以去做这个工作,同时这个工作需要的最短时间有多少?
    3)有多少人可以参与这个工作?
    4)是否有一定要做出来的决心和精力?
这几点问题是关于这个工作成败的关键。
    我觉得这件事情本身是富有趣味性和挑战性的,如果你有关于这方面的电子版的资料,Mail 给我一份,我需要了解一些技术细节。
    关于下载的问题,很不幸的就是我们公司的代理限制的更严,仅能访问有限的一些站点,并且速度奇慢。
    另外,关于C++编译器的问题,我认为如果你有Minix a.out 的文件格式,另外由于gc++编译器的源代码是开放的,我们可以将其修改为Minix下的C++编译器,有关问题我们可以请教 Al Woodhull 及其他人员。当然如果有其他现成的编译器就更好了,可以Mail给 Al Woodhull问一下。
 
他很快回了信,对我的问题一一作了回答:
 

>1)你是否对面向对象的操作系统的几个特性有了充分的理解和认识,并且对如何实现它有了一个比较成熟的想法(关于面向对象操作系统的几个特性的实现方法)?
 
事实上,一开始我们可以不要过多的考虑那几个特性,因为那是当我们有足够的实力,时间和经验时,才可以去考虑的事情。我现在的目的其实很简单,说白了就是希望将现有的系统全部用c++代码来代替掉,其实这已经意味着有很多工作要做了。
 
>2)你最多有多长的时间可以去做这个工作,同时这个工作需要的最短时间有多少?
 
满打满算,我最多有1.5年来做这项工作,直到毕业(当然毕业以后也可以干)。
这个工作需要的最短时间,我不敢预测,别见笑,确实不敢预测,我的想法是在毕业时,能拿出一些东西给别人看,就算没被干。
 
>3)有多少人可以参与这个工作?
 
你想在当前的中国,有几个人愿意跟你做操作系统,要不中国IT业也不致于这样衰。目前,前前后后张罗的人就本人一人,当然还可能争取过来几个,不过这要看运气了。
 
>4)是否有一定要做出来的决心和精力?
 
首先精力是不成问题的,我就是专门做这个的。如果事情进展地顺利,我指的是如果编程方面没有了问题,同时能拉过几个人来,我就干定了,大不了不要这个学位了。
 
>我觉得这件事情本身是富有趣味性和挑战性的,如果你有关于这方面的电子版的资料,Mail 给我一份,我需要了解一些技术细节。
 
说真的,我也没有这方面的电子版的资料,我的一些资料全是网上查找的。但由于现在忙着解决如何编程开发的问题,所以关于面向对象的操作系统的一些理论上的东西,我也没有多少了解(有关这个问题,我们可以专门找时间来切磋)。我个人觉得其实不需要太多的理论,只要能解决掉C++中关于操作系统相关性的部分(例如生成一个对象的new操作符,必须自己做,不能用编程系统提供的,因为这是系统相关的)。
 
>另外,关于C++编译器的问题,我认为如果你有Minix a.out 的文件格式,另外由于gc++编译器的源代码是开放的,我们可以将其修改为Minix下的C++编译器,有关问题>我们可以请教 Al Woodhull 及其他人员。当然如果有其他现成的编译器就更好了,可以Mail给 Al Woodhull问一下。
 
Minix a.out的文件格式不成问题,代码中有。但关于修改gcc为Minix下的C++编译器的事,我不敢瞎说,因为不怕你笑话,我是学数学出生的,没学过编译,对此我是门外汗(看了这句话,你不会不理我了吧!)。事实上,Minix2.0因为不支持虚拟内存,而C++编译器简直就是一个吃内存的大怪物,所以将gcc移植到Minix2.0上基本上是可以判死刑的---没戏!我在comp.os.minix新闻组上不止一次看到过类似的说法,好象Al Woodhull 大叔也这么说。现在你应该明白了为什么minix-vmd上可以移植gcc了吧,因为它支持虚拟内存。但我给Al Woodhull发过一个email,问他在minix-vmd上生成的可执行文件可不可以直接在minix2.0上运行,如果不行,有没有工具进行这方面的转化呢?结果他说,他也不太清楚,反正没回答到点子上,不过他说他把我的email转给了kees j.bot,但"酷人"kees J.bot至今仍是杳无音信,大概他不愿回答我们的“愚蠢”问题吧。(另:附件中有Al Woodhull给我的回信)
 
这次通信的邮件就成了我们对计划设计和开发的OS的目标定位和开发计划的说明,非常的模糊。更要命的是,当时我们对于制作OS的方面的知识知之甚少,我们打算使用C++来开发面向对象的OS,而当时我们对C++根本就不熟悉。但当时我们对于OS都满怀着极大的热情,于是没有考虑更多的问题,就开始上路了。
 
这中间我们还有幸结识了几位比我们两个在OS方面有经验的多的国外的朋友,他们也加入了我们。我们建立了自己的Mailing List,那段时间我们5个人进行了大量的讨论,也尝试着开始做一些设计,并开始写相关代码。但由于最初所定的目标很模糊,我们花了更多的时间来争论——究竟是做成微内核的,还是做成整体内核的,是使用NASM,还是使用AS...等等类似的问题——逐渐有人开始对此感到厌倦,开始很少参与讨论,其实也就等于退出了小组,毕竟大家还有自己的工作。5个月之后,我突然接手一个压力极大的项目,也退出了小组。半年之后,当公司的项目忙完之后,我试图和他们联系,但邮件都被退回,这个计划最终失败了。尽管我在这个过程中学到了不少东西,但给我印象更加深刻的是,如果一件事情,你不十分清楚你的目标及计划,那么这件事情基本上从一开始就失败了。
 
对于这个问题,在Internet上有一篇广为流传的经典文章,不妨借花献佛,引用于此。
 

0.1.2 Questions For an OS Designer

Here are questions that you should answer before you start to code an OS. It's not a secret that every program must be designed before it is written (implemented). Also it's not a secret that a very few of programs are written this way... Most are written under pressure and hardly have a complete requirements list when coding starts.

Such an approach is very harmful. Design is finished in breaks between coding work and is dictated by things that are already written and work. Programmers tend to think "I'll change it later" but mostly later never comes. Nobody really wants to change already working code to fit a changed design.

It may be very painful if you write an OS. Because of design flaws or incomplete design the whole project may be brought down or at best take months to redesign and rewrite big parts.

Answering questions suggested here will not form a full design specification. However it will not let coding go completely off road. All of them should be answered before writing a line of code. Certain questions may be ignored if they are irrelevant, e.g. you don't need to think about file systems if you don't plan to support mass storage devices. From the other hand, all the answered questions should not contradict. Where I feel necessary, hints are typed as italic.


  1. What is a primary goal of my OS?
    • Is it a standard (low end) desktop system? User is dummy, highest priority for hardware and software compatibility.
    • Is it a high-end desktop system? User is CAD/CAM engineer, highest priority for performance and certain hardware/software compatibility.
    • Is it a real-time oriented system? User is a professional programmer, highest priority for performance, defined response time, easy extendable hardware support and programming control.

  2. What platforms my OS is going to support?
    • Will it support multiprocessing?
    • What kind of multiprocessor platforms? Symmetric? (all processors are exactly the same). Asymmetric? (CPUs may be different in architecture and computing power). Both?
    • Will it support only local multiprocessing? (all CPUs are connected through a local bus). Distributed multiprocessing? (CPUs are connected through network-like connection). Both?
    • What is the target hardware system? Desktop? (more or less standard hardware set). Customizable (embedded) hardware? (If the latter is an answer you'll likely have to individually support every even compatible processor).

  3. Will it be a multitasking OS?
    • What kind of multitasking will it provide for applications? Cooperative? (tasks yield CPU when they don't need it, demonstrating good will). Preemptive? (tasks are given a defined amount of CPU time).
    • Do I need to protect tasks from each other well?
    • What is a relationship between tasks in terms of living space? Do they share the same address space? Completely separated? Both?
    • How will different tasks communicate with each other?
    • What will be a memory model of space that a task runs in? Should I favor simplicity and speed (memory is cheap) or size (memory is a scarce resource)?
    • Do I need to protect system from application tasks?

  4. What file system will my OS use?
    • Should I favor access time (performance) or reduced storage space (size)?
    • Can I use one of already developed and well documented file systems?
    • Can I use a cut down version of one of well-known file systems?
    • What will be an executable format?

  5. What build tools do I need?
    • Can I use one of existent compilers and linkers?
    • Can I obtain (for free, buy or lease) source code for compilers and linkers?
    • Do I have to write my own several tools?
    • Do I have to write all tools on my own?This should be by any means avoided.

  6. How can I easily support third party soft?
    • Can I support already existent and popular software?
    • How can I support easy creating of third party applications for my OS? (Libraries)
    • How can I support easy creating of third party device drivers?

  7. How can I use already written code and information?
    • Can I use code that is written by others and works? (Even partially).
    • Where can I get different kinds of information? (Set your own information library).