>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 x86_64 segment registers ( in long mode ) are all 0 based ( except for FS and GS)
Also im not sure what the above gets you. Forks are not common ( in terms of instructions) so im not sure perf even matters. Normally an app loads from the disk and then it creates a sub proc via a fork , when comparing to a disk a few micro seconds to copy the memory is not a big deal. > >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). I only need to get fork working for mono , if we are talking about apps this only affects data for shared static code, GC references are always indirect/private. Everything else can be patched at load. Static code can be handles like TLS either store it as an Offset to FS ( on x86 ) or a spare register in (x86-64). I know ucLib already has code for this. Note this is more an issue for monolithic OS than a microkernel as you don't really have or rely on as many shared libs. A 3rd alternative I have proposed ( for the .NET & Java apps) is for shared code to be broken into 2 libs and any methods that access static data to be placed in a separate lib and that code is not shared. It can then be patched as normal for full performance and code that is static heavy will be penalized with additional memory use but no perf penalty. > >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. Fork was around before copy on write, why not just do it the old way and have the child treated as a new process ( though we need to repatch the code to point to the new location ) ie the fork copies the data AND code. ( note this is not my architecture since there is no fork but just to get it all up and running) > >> 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 :-( :-( Anyway this is getting away from the discussion , I just need to get ( hack) mono into working and that is it , why fork was not implemented was a curiosity. _______________________________________________ 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
