From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7871fcf50709061015u3354f721ga0bddab13a3ed49@mail.gmail.com> Date: Thu, 6 Sep 2007 13:15:18 -0400 From: "Joel C. Salomon" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] plan 9 overcommits memory? In-Reply-To: <46DEE273.243B2292@null.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46DDB9AD.DF4673BE@null.net> <46DEE273.243B2292@null.net> Topicbox-Message-UUID: b99f2efc-ead2-11e9-9d60-3106f5b1d025 > > > That's why many OSes have a "spawn" primitive that combines fork-and-exec. > > > > the problem with spawn is it requires a mechanism to replace that little > > block of code between the fork and exec. that code is hardly ever the > > same so spawn keeps growing arguments. > > Yes, on the other hand I bet a spawn interface could be devised that > is sufficiently programmable. (May require some extra dup()s etc. to > really handle all the common usage patterns.) What could accomplish this are hooks into the process-creation bits of the kernel. I've lost the links to this, but some toy OS accomplished process creation with the equivalent of 'cp /bin/ls /proc/clone'. This isn't useful on its own, but it could be an interesting exercise to construct a process outside the kernel and kick-start it somehow. The one somewhat useful application of this idea would be to mitigate the bug documented in notify(2): Since exec(2) discards the notification handler, there is a window of vulnerability to notes in a new process. In a hand-rolled spawn(), one could conceivably install a notification handler before the process starts executing or accepting notes. Possibly some form of dynld() could be built on this too. I can't imagine that either of these uses are nearly compelling enough to open this can of worms.... Has anyone truly felt confined by Plan 9's fork+exec model? --Joel