On Fri, 2007-01-05 at 15:39 +0100, M. Koehrer wrote: > Hi everybody, > > I have a question that is similar to the one concerning the system() call out > of > a real time context. > I want to create a flexible framework that allows dynamic loading of shared > objects > during runtime. (The loading itself can of course not work in real time). > The main application itself should run for a very long time (a couple of days) > and during that long run time I want to load and unload small pieces of code > that > have to be executed. > After loading a .so file I want to hook loaded routines into the (already > existing) real time context > of my main application. > Is it possible that this kind of operation can cause any memory issue similar > to that > I detected in the 2.6.19 kernel (the system() call out of a real time > context)? > I ask as the dlopen() call probably extends the valid address range of the > current > process. >
The initial VM_NOCOW patch only affects the mm copy code on the process fork path, not the mmap code. And shared libs do depend on COW, for relocation fixups and other issues. In short, I don't think dynamic binding would be safe wrt COW handling using this patch. However, the recent VM_NOFAULT patch Gilles has just posted to the -core mailing list should solve the issue: the point is to have COW pages excluded from all VMAs mapped by a (real-time) task, and this is what ipipe_disable_task_faults() does among other things. You might also want to try telling the dynamic linker to resolve all symbols from your shared libs at startup using the LD_BIND_NOW boolean variable; maybe this would prevent further fixups involving COW breakage. Static storage data defined by the library that might need to break COW and as such generate a fault are another issue though. > Thanks for any feedback on that question. > > Regards > > Mathias > > > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
