Thank you very much Dong; See bottom. On Tue, 2008-05-27 at 18:55 +0800, Dong Feng wrote: > > I have some thought on this topic. I don't see any inventors of Unix > said why the fork-model was chosen exactly. But I believe the fork > well conforms to some basic Unix principles, if not intently, at least > coincidently and so be persevered by natural selection over time. > > Among other principles, Unix has two important principles, > 1. Each component should do one thing, and do one thing well. Check mark > 2. Fundamental component (especially like kernel) should provide > mechanism rather than policy. Policy: "To regulate by laws; to reduce to order." > Among the kernel's jobs, to create a new task and to decide what new job the new task should do are two separate things. Although most of newly-created task is to load another executable from the disk, but that's not always the case. A newly-created task may run the same code as its parent, with the same or different input, or it may load new executable code from network or other media than disk, or it may even compute new code by its own. > > Therefore to implement a system call that creates a new task AND loads > new executable code is a bad idea. > If you insist to do so, you come across the second difficulty that is > how you determine the way the new executable code is loaded. To > enforce the new code always loaded from disk is crude. > To provide several predefined way is better, but still it enforces policy to users. > > On the other hand, to create an empty task is also not practice. Can > an empty task exist at all? I don't know. But how an empty task decide > what it go next step. It can't. So either kernel or another task > should make decision for it. > Kernel should not provide policy so it shouldn't make such a decsion. > Another task doing so will violate process separation basically. To > let the newly-created task duplicate its parent is a handy and elegant > choice. > It involves only memory operation (and by COW the memory opt is also > minimized). COW: "copy on write" > It does not violate process separation and make the child-process have > maximal flexibility to decide what next step to go. So fork() does one > thing only and well and push as much policy as possible up to the user > space. Gotcha > > OK, at last, after all, to load a new executable from disk is a usual > operation so Unix provides exec(). > But be aware two things, > 1. exec() is one of the many choices you can do after a fork(). > 2. To be invoked after fork() is one of the many cases exec() is used. > exec() does not necessarily pair with fork(). That single point actual > proven it is completely correct to separate them. > They are orthogonal. And orthogonality is the most beautiful things > science and engineering pursue. To put it crudely: They bounce off of each other; have some similar characteristics acquired from each other but go in a different direction; getting two for one so to speak. > And again, I don't read anything like above from the history or > stories of Unix. It is completely my own understanding from the > articles and words spread in several books and many web pages plus the > result of my own crude mental activities. Hope it answer you > questions. > [snip] Dong, I have taken the liberty of breaking down, or separating out the parts of your post that I needed to emphasize to myself. No reinterpretation intended. I have not read been able to read or find any answers to 'why' either. Yours is a very thoughtful explanation, put together from a much deeper understanding of what is happening than I have. I appreciate the time and effort. Whether, in the end, your explanation is absolutely historically accurate doesn't really matter. It is a clear explanation of basic principles I can retain as a mental image and use as a reference as I try to solve my own programming problems in the future. > > > > > -- Regards Bill -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
