-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am confused about how the implementation of vfork for non-MMU devices works. It's late, but I'm pretty sure it *can't* work, and would like to know if anyone has any non-MMU devices where init starts properly.
What it does is to create a child task and then go to sleep. The child longjmps back into the parent task's stack, vfork returns, and the child runs code until it calls exec() or exit(). At this point the parent wakes up again and continues executing. Except that because both the child and the parent are running on the same stack, and the child is *returning* from vfork, won't the child trash the stack that the parent is going to need to use when it wakes up again? What's worse, when the new task is created, no new user-mode stack is specified. This means that the new task runs on the same stack as the old task --- but starting from the top again, so overwriting the old task's stack, resulting in horrible stack corruption. Has anyone seen this work? - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ } │ --- Conway's Game Of Life, in one line of APL -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMBu+bf9E0noFvlzgRAmwcAKDd5GLLxjxw2r4RZFdibLsMsWkl8gCeOhb8 wHm9TTlTkllvabRnWztuefI= =2AfL -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Prex-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/prex-devel
