Jivin Michael Schnell lays it down ... > > >No, not exactly either. Almost all of the current code in the kernel > >for non-mmu is conditional on CONFIG_MMU. > With user space stuff I always found the "EMDED" define which often is > used to do a fork() vs. vfork() selection. > > (Which IMHO in many cases seems silly, as AFAIK, you can happily use > vfork() if there is > an MMU, too, in nearly (?) all cases when you can _simply_ (without any > other code change) replace fork() with vfork() anyway. )
That is true, but to be sure everything is happy, it's often better to continue using fork on MMU systems, especially if there is any question over the safe use of vfork. > Moreover the name of the "EMBED" define seems quite outdated, as today, > many embedded devices do provide an MMU. Hmm, I thought that current SG/uClinux-dist mostly used EMBED for things that reduce code size (and often functionality at the same time) and __uClinux__ for true uClinux (ie !MMU) changes. > I don't know if there is some change on that issue planned (e.g. using > CONFIG_MMU, in User Land as well). In user space we use __uClinux__ for vfork/MMU differences. Cheers, Davidm -- David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
