Pondering NOFORK annotation...

[Rob Landley]

On Sunday 23 July 2006 2:00 pm, Shaun Jackman wrote:
> On 6/14/06, Rob Landley <rob at landley.net> wrote:
> ...
> > That leaves a full 3 bits leftover that could be put into a 
applet->forkage
> > value, for which I currently can think of three values (BB_MUSTFORK,
> > BB_NOEXEC, BB_NOFORK) which could fit in 2 bits.  So life is good.
> 
> I like this line of thinking. Perhaps this flag could also specify if
> a particular applet would be happy with a vfork, or if it requires a
> full fork.

The hard-to-handle case with vfork is where it wants to fork but not exec.  
Generally, to do that with vfork you have to exec yourself (which gets us 
back into the /proc/self/exe hack, or similar).

I'm pondering some way for applet.c to save the info we need on the way in, 
but if you do a chdir() or chroot() you can completely lose access to your 
original binary.  (Yes, even chdir.  Overmount a directory you're still in 
and you can access it through "." but not anywhere else.  Yeah, bit of a 
corner case...)

> One applet I can think of off the top of my head that requires its own
> data space (read fork or vfork/exec) is hexdump, because it use
> freopen on the stdin stream.

It can be rewritten not to do that.  But a very common case of "fork yourself" 
is daemonize(), which we have a bad workaround for in the tree now.  The 
shell code is likely to go a bit funky with this too.  (builtin_applet &)

Lemme finish converting converting the repository, rewriting mke2fs, and 
redoing getopt_ulflags(), and then I'll tackle bbsh and make standalone.  
(Those are my two big "wanna get this done for 1.3" items.)  Getting vfork() 
cleaned up is tangled into bbsh because it's a pain to deal with under the 
current mess 'o four shells...

> Cheers,
> Shaun

Rob 

P.S.  At OLS, I got armulator to work.  I have a nommu test environment now!  
Woot!
-- 
Never bet against the cheap plastic solution.