Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ames!uhccux!munnari.oz.au!metro!natmlab.dap.csiro.au!ditsydh.syd.dit.CSIRO.AU!evans
From: evans@syd.dit.CSIRO.AU (Bruce.Evans)
Newsgroups: comp.os.minix
Subject: Re: minix manual, exec from init
Message-ID: <1990Nov16.095145.5873@syd.dit.CSIRO.AU>
Date: 16 Nov 90 09:51:45 GMT
References: <36227@nigel.ee.udel.edu>
Organization: CSIRO Division of Info Tech, Sydney, Australia
Lines: 21

In article <36227@nigel.ee.udel.edu> archer%segin4.segin.fr@relay.prime.com (Vincent Archer) writes:
>The INIT (pid=1) in the Minix kernel is not just like an ordinary process. It
>is put in a special way, with a special binding, in a special location. As an

It's true that INIT has special properties. However, an exec()ed version of
it will inherit all the relevant ones, with the possible exception of the
location. The location should not matter, since INIT has no trouble forking.
There is probably some small detail being messed up that stops it from
execing.

>but BEFORE any other running program. Another example is that CTRL-ALT-F9
>kills all processes, but leaves INIT untouched. So exec-ing is strictly
>forbidden when you're not a user-level process (try exec in FS :-> ).
>
>That's why Fred van Kempen, in its INIT, forks() and then exec("/etc/init")

You just explained why a fork+exec'ed version won't work so well :-). It
will not have all the necessary special properties such as immunity from
kernel signals.
-- 
Bruce Evans		evans@syd.dit.csiro.au