[BusyBox] Trouble with busybox-1.00-rc2 (Follow up: It was vfork's fault)

[Νατσάκης Κωνσταντίνος]

 Today i managed to narrow down the problem..

 I found out pre9 worked fine but pre10 didn't..
 It seems that the following change was applied between pre9 and pre10:

 --- busybox-1.00-pre9/init/init.c       Mon Mar 15 10:28:40 2004
 +++ busybox-1.00-pre10/init/init.c      Mon Apr 12 22:21:54 2004
 @@ -53,7 +53,7 @@
  #endif
  
  
 -#if defined(__UCLIBC__) && !defined(__UCLIBC_HAS_MMU__)
 +#if defined(__UCLIBC__) && !defined(__ARCH_HAS_MMU__)
  #define fork   vfork
  #endif
  

 My uClibc has MMU support compiled in.
 So when i use busybox 1.00-pre9 fork is used.
 And when i use pre10 vfork, since  __ARCH_HAS_MMU is not defined.

 I found the following in glibc info pages which i assume are valid for
 uClibc's vfork too:
  - Function: pid_t vfork (void)
      The `vfork' function is similar to `fork' but on some systems it
      is more efficient; however, there are restrictions you must follow
      to use it safely.

      While `fork' makes a complete copy of the calling process's address
      space and allows both the parent and child to execute
      independently, `vfork' does not make this copy.  Instead, the
      child process created with `vfork' shares its parent's address
      space until it calls `_exit' or one of the `exec' functions.  In
      the meantime, the parent process suspends execution.

 So thats why init (pid=1) was going to the D state i guess..

 Why did busybox developers chose to use vfork in this case?


-- 
cyfex