Lennart Sorensen wrote: > > lies. there are no serious limitations at all with FDPIC ELF. it is > > functionality equivalent to ELFs running under a MMU. > > Well I haven't looked at FDPIC ELF since it doesn't work on m68knommu yet. > > > you cannot do fork() without virtual memory since both processes will have > > pointers to the same addresses and there's no way to relocate them. > > OK, I suspected that was the case.
You could do what Minix does. That is to copy the process writable data and swap it on context switches - a big memcpy. That's a big performance hit, but for process which do fork-then-exec (most of them), it's only one copy, and avoids the special issues of vfork. Maybe that would be worth adding to uClinux for the convenience and portability improvement, despite the big performance hit. Then "vforkizing" packages (which is often done wrong) would be for optimisation not necessity. > > memory protection is not strictly part of the MMU. some > > processors implement MPU's (like the Blackfin processor) and the > > kernel supports it just fine. that gets you standard > > data/instruction rwx control. > > OK, I had never heard of it done that way before. That's neat. > Certainly not typical of a nommu system though. Fwiw, there are m68k systems which implement a similar no-mmu protection scheme. I played with one around, oh, 1989 or so :-) I don't know if any still do this and run Linux. -- Jamie _______________________________________________ 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
