Jivin Mike Frysinger lays it down ... > On Friday 09 April 2010 00:36:38 David McCullough wrote: > > Jivin Ben Kloosterman lays it down ... > > > Fork is the big question mark , speaking of which why didn't uclib > > > support fork and instead of copy on write ( like early unix fork) just > > > change fork to copy on fork or are the API differences to big ? > > > > You can't just copy on fork (unless it's a truly big copyin/out on every > > context switch). Pretty sure this has been beaten to death in the > > uClinux-dev archives somewhere ;-) > > isnt that exactly what minix does though ? crap performance sure, but it > lets > things get a basic port going easier ...
On x86 you can play tricks with the segment registers which can allow memory at different locations to look the same to the running process when using the appropriate code models. Thus, you can copy the data of the parent for the child to use and it doesn't have to be at the same "real" location in memory because a segment register is different at the process level. On things like m68k/arm etc, you would need compiler mods to make sure all pointers/data access/structures never had any absolute references to stack or data space (never), they must all vector through some "register" that was global to the process and could be changed in the child. These compiler changes would make the code very inefficient (double indirect on every data access of any kind). If your CPU arch has some rudimentary segmenting/addressing modes it may be easier. The only other option that will always work is to copy the parent memory out (to somewhere else) and copy the childs in on each context switch. While it is possible, I think the performance drop would be so high that the usefulness of such a feature is far outweighed. > the kernel would have to do the copy. no way it could be handled in > userspace Yes, in kernel, it basically becomes a big swap to other memory or disk on all overlapping context switches so that things are where the code expects. For whatever reason I can't find any of the old discussions on this even though I know they are out there :-( Cheers, Davidm -- David McCullough, david_mccullo...@mcafee.com, Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org _______________________________________________ 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
