Jamie Lokier <[EMAIL PROTECTED]> wrote: > It's not XIP in ROM, but is sharing code segments in RAM in the same > way (and same compiler options), which is critical for my application. > It reduces no-MMU fragmentation considerably.
I know. The ELF-FDPIC binfmt was developed alongside the revised NOMMU code. > You say private R/O - not shared R/O? Shared R/O must be effectively shared with the backing store, so copies are explicitly _not_ taken. Private and shared R/O are both capable of XIP if the backing device supports it (as specified in mapping->backing_dev_info->capabilities by the BDI_CAP_ flags). Note that in 2.6 both the ELF-FDPIC and FLAT binfmt drivers use private R/O mappings for their text segments. This permits copies of the code to be taken, and also permits ptrace attachment to prevent copies being taken. David _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
