From RTEMS to Linux :-(

[Alan Cudmore]

Leon,
Another possibility is to use a higher level library like glib:
http://library.gnome.org/devel/glib/2.22/index.html

Glib is one of the core libraries for the GNOME desktop. It has many  
RTOS-like primitives, and it is portable to Linux, windows and OS X.
The only thing I'm not sure about is using it in a non-gui  
environment, without a main event loop.

Here is the section that has memory management, lists, queues, trees,  
etc:
http://library.gnome.org/devel/glib/2.22/glib-data-types.html

There are other C++ libs out there like QT, and boost that may help.

Alan


On Mar 23, 2010, at 1:57 PM, Leon Pollak wrote:

> On Tuesday March 23 2010, Gedare Bloom wrote:
>> Linux programs are mainly stuck with the POSIX API to the kernel and
>> whatever you can find in libraries (libc, etc) -- which are usually
>> built on top of POSIX. Certain types of low-level operations, such as
>> allocating physically contiguous memory, is not (to my knowledge)
>> possible from within a user-land application and is not specified by
>> POSIX.  There are kernel interfaces that provide such operations for
>> kernel-mode code such as device drivers and kernel modules, but I
>> don't think there are any user API functions to access them.
>>
>> I would suggest formulating a set of questions specific to what you
>> are trying to do, and then ask them on some appropriate Linux mailing
>> lists (e.g. http://www.linux.org/docs/lists.html and
>> linux-c-programming).  My guess is that most of the functionality you
>> need is available somewhere in some library, but the trick is how to
>> find it.  If you do need low-level functionality (i.e. hardware
>> dependent) then you will probably have to write a kernel device
>> driver.  There are also good resources online for how to do this, for
>> example http://lwn.net/Kernel/LDD3/
>
> Thank you, Gedare.
>
> No, I almost do not need to do low level programming (and I  
> understand just
> for now how to do it). My user space main program is in processing  
> of data
> received from low level driver in several stages.
> In RTEMS I should do it simple: create a partition, pull the buffer,  
> give it
> to the driver to fill, pass it to the processing task(s) and free it  
> at the
> end.
> I found POSIX threads (look a bit awkward from RTEMS task point of  
> view, but
> still usable), mailboxes and signals (analog of semaphores?). But no  
> traces of
> something similar to partitions....
> This made me think that I am on the wrong way...
> -- 
> Leon.
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users