From: Philippe Gerum <rpm@xenomai.org>
To: Stephan Zimmermann <s.zimmermann@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] RT Heap in Userspace
Date: Thu, 12 Jan 2006 16:49:20 +0100 [thread overview]
Message-ID: <43C67A80.40100@domain.hid> (raw)
In-Reply-To: <200601121136.38271.s.zimmermann@domain.hid>
Stephan Zimmermann wrote:
> Hello again,
> based on your information about memory allocation, I tried out the following:
>
> in main:
> // creating the Heap
> ret = rt_heap_create(&rt_heap,"Main-RT-Heap",rt_heapsize,H_FIFO);
>
> global:
> // overloaded operator new
> void* operator new(size_t size){
> void* newmem = NULL;
> int ret = rt_heap_alloc(&rt_heap,size,TM_INFINITE,&newmem);
> printf("new memory allocated: %i bytes, return %i\n",size,ret); fflush(NULL);
> return newmem;
> }
>
> This works fine, as long as I use a standard 'malloc' in my operator new. When
> executing the rt_... code, creating the heap returns 0 as expected. But
> trying to allocate some Memory insode of it using operator new fails with
> -EEINVAL.
>
> Reading the API-Doc more thoroughly, I saw a statement that H_SHARED is
> implicitly set, when a heap is created from Userspace (where my program
> executes).
> So, is ist possible to do what I try, or will I need to run in kernelspace for
> it? Maybe there is some 'trick' to do it?
>
Not yet. For the time being, user-space heaps are always built as single shared
memory segments, which is a useless limitation. There is a plan to fix that in a
reasonable future, by decoupling the mappable heap property from the
single-segment one (i.e. which will allow in turn to create shared heaps which are
not necessarily single-segment areas). If your application can bare higher
execution latencies as a result of calling the allocator for a while, then you
might consider sticking with malloc until this fix is available.
Sidenote: going for kernel-space with C++ always seemed to me a bad idea. It's not
that it is impossible, it's just that it often turns out to be a maintenance hell
provided you want to keep your options reasonably open regarding your kernel+gcc
combo of choice.
> Thaks for your help, Stephan
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
next prev parent reply other threads:[~2006-01-12 15:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-12 10:36 [Xenomai-help] RT Heap in Userspace Stephan Zimmermann
2006-01-12 15:49 ` Philippe Gerum [this message]
2006-01-12 23:14 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43C67A80.40100@domain.hid \
--to=rpm@xenomai.org \
--cc=s.zimmermann@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.