On Fri, 2006-12-22 at 12:40 +0100, M. Koehrer wrote: > Hi Philippe, > > I agree. To fix the root cause is actually the very best to do! > This eases the life of users and developers.
Definitely, yes. The point is that once you go down the "rt_task_system()" path, you end up being trapped into API proliferation, which would continue with rt_task_fork, rt_task_vfork and so on. This would a dead end, unfortunately. Asking people to use rt_task_system() is already asking them to understand why they should not use system() in the first place, so this can't solve the root issue. The problem comes entirely from the fact that we don't expect any more faults after mlockall, and COW proved us wrong. The fact that the machine freezes is only a side-effect due to the co-kernel constraints, the first and foremost problem is that gracefully handling a page fault would induce uncontrolable latencies anyway. IOW, the problem has to be fixed at kernel level, because it's fundamentally an arch-dependent core issue. > > Regards > > Mathias > > > > > Sorry, but no, no way, I won't merge anything like this, ever. This is > > the wrong way to go. The right way is to fix the COW issue at kernel > > level - probably the I-pipe has to provide the required support - > > because this is where those dirty details belong to. This is definitely > > not an API issue, because you just cannot tell application developers to > > care about arch-specific VM issues when using a so-called generic API > > that has to work the same way on all archs (e.g. MMU-less platforms > > don't care about this, others would). What could be considered as a > > bearable limitation right now must not have any impact on long-term > > principles, and the API stuff belongs to that category of issues. > > -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
