On 21/12/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Gilles Chanteperdrix wrote:
...
>> static void realtimetask(void *arg)
>> {
>>     system("ls -l");
>
> If you want to use system (or any function calling fork, eg popen or
> vfork) with Xenomai, you have to make sure to fault all pages mapped
> with write permission after the fork before trying to use services in
> priimary mode, because fork write protects all pages with write
> permission and notably the threads stacks. A piece of code that faults
> all pages follows.

Let me check if I got this correctly: fork calls mark all pages
write-protected - also those of the father process, or only those of the
new child?

It's copy-on-write policy. fork() creates a separate address space for
a child (vm_struct, vm_area(s), all the page tables) but it still
points to the same physical pages as parent's address space. Now what
if either a child or parent want to modify writeable pages? That's why
copy-on-write. A new page will be allocated when a write request is
commited. And yep, to address this issue, the vm areas of (in fact,
related areas in page tables) both parent and child are marked as
copy-on-write.

But I don't think this is an issue here :

1) by the moment system() returns -> the child has finished and there
is no need to allocate new pages on parent's write requests (not sure
how linux handles it - have to check);

2) (I'd expect logically) the parent did mlockall() in advance for
even future allocations, so I'd expect copy-on-write is not applicable
fot it -> all the pages should have been duplicated for a child. Well,
it's a brief idea. Have to check.

so it's likely that it's just a side - effect.

Mathias: if printf() helps (after system()) so could you try e.g.
fopen(), fclose() instead? Also, please, do what previously was
suggested with rt_task_delete(NULL) at the end.

Another situation would be if one does fork() in real-time app. and
then both parent and child continue their execution (worth checking).

p.s. vfork() is a different beast. Here a child is supposed to call
exec*() rigth after fork() so it's allowed to "borrow" parent's
address space (vm_struct -> all vm_area(s)) and the parent is blocked
in the mean time. As a result, no need for copy-on-write.


--
Best regards,
Dmitry Adamushko

_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to