[Xenomai-help] Re: Re: A fairly small rtnet/Xenomai...

[Philippe Gerum <rpm@xenomai.org>]

On Fri, 2006-12-22 at 11:27 +0100, M. Koehrer wrote:
> Hi Gilles,
> 
> > fault_vm is safe to use only if you are calling fork at a time when
> > there is only one thread. So, if your application is forking at init, it
> > should be OK.
> Do you mean there must be only one real time thread? 
> That means, when I have an application that creates multiple real time threads,
> I can not rely on fault_vm() ?
> In this case I have to do the "hard" way by using a different (non real time)
> context to do the forks and system() calls.
> As this is hard to understand, I strongly recommend that there is Xenomai support
> for this! I.e. a Xenomai API that can be called with a (callback-)function pointer and
> a user data pointer. 
> When a (realtime) thread calls this function, the real time thread is blocked. 
> The callback function is then called from a safe context and
> after exit of the callback function the real time thread is resumed.
> 

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.

> Regards
> 
> Mathias
> 
> 
> 
> 
-- 
Philippe.