On Tue, 2010-08-17 at 14:25 +0200, Krzysztof Błaszkowski wrote:
> I found recently that large application uses to segfault before fork()
> leaves its glibc wrapper.
> I included here a test suite which can be easily used to verify what
> goes wrong. It may be necessary to adjust makefile to compile the code.
> So, the console is missing output from line #89. We can see instead a
> message that getpid couldn't be linked which is 1st sign of memory
> i used to think that this issue could be related to not unbinding heap
> before fork() but it turned out that it is enough to link userspace with
> xenomai libraries.
> I wonder if this is known issue and if there is any fix, does 2.5.4 work
> same ? or maybe there is something wrong with the kernel i use (or adeos
> Another question is why rt_task_create() is marked deprecated in native
rt_task_create() as defined by the kernel-side API is marked as
deprecated. The user-space version of rt_task_create() is not.
> Does it mean that native skin is going to be removed from source
> tree ?
No. It means that starting with the next major evolution of Xenomai
(i.e. 3.x), skins will no more export any kernel-based API (except
RTDM). In short, if your application is running in user-space, nothing
will change for you. OTOH, applications currently running in kernel
space over the native API should consider moving to user-space at some
point, because we won't support the former programming model
indefinitely. The rationale for this decision is explained here:
The keyword here is "application", obviously not drivers, which are by
essence better supported in kernel space in the Linux environment, and
Xenomai 3.x will keep on providing what is required to develop them
there over RTDM.
> Xenomai-core mailing list
Xenomai-core mailing list