[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
need a quick allocation tutorial
- Date: Mon, 9 Aug 1999 15:44:49 -0500
- From: ccaudle at pdq.net (ccaudle)
- Subject: need a quick allocation tutorial
I am in need of some kind soul to give me a quick tutorial on the relationship
between the library provided allocation function malloc() and the rtems region
and partition directives.
For a first basic question, where is the configuration control to make sure
that memory allocated with malloc isn't using the same memory which is being
managed by the partition and/or region managers? Is malloc actually
implemented as a wrapper on top of the partition manager, or are they managing
separate memory pools?
I assume that the whole point of using partitions and regions is that it is
faster and/or more deterministic than using malloc?
The context of this question is that I need a wrapper function to go between a
device driver library and RTEMS memory management.
The library is made to be portable, so it just calls out a function for memory
allocation, which must be supplied by the OS/executive using the library, with
an argument which can specify requirements of the allocation.
Most of the requirements are a non-issue for RTEMS, such as
"virtual=physical,"
"non-pageable," etc. that would be a concern in a multi-process paging OS.
The flags of concern (i.e. How do I map these into RTEMS calls?) are
"non-blocking," to indicate that the allocation must not block when called (so
that it can be called from within an interrupt service routine, I assume), and
an alignment parameter to specify memory alignment.
I haven't seen anything in RTEMS memory management which lets you specify
alignment.
When I get something working I'll post the information I have. I'm interested
in the library for block storage devices, but it includes lots of network
device drivers, as well as a portable wrapping of the BSD network stack.
There seem to be a lot of people looking for network device drivers, so it may
be of interest to several on the list.
-- Chris Caudle