RFC - Memory Partitioning

[Robert S. Grimes]

I've been thinking about this for a while too.  I haven't anything too
concrete to suggest at this time, but I don't want to see your post die
on the vine.  I do have some observations about the nature of the
proposed beast...

One thought is that this move could result in the POSIX API becoming
more in line with other implementations, if each "partition" could act
as a "process" in the proposed RTEMS.  This would allow developers the
usual choices of multi-process, multi-threaded (I like to think of RTEMS
"tasks", in traditional API-speak, as "threads"), or combinations.

Another thought is that truly hard-real-time activities could run in a
suitably "high priority" partition, using such things as the rate
monotonic scheduler, and softer code then could run in other partitions.

I certainly would not want to eliminate the current model of RTEMS,
especially wrt low overhead, high performance on "smaller" systems,
especially those without MMU.  A rather simple-minded idea could be to
think of such systems as "single partition" systems, which might lead to
a useful guiding principle: In the proposed new RTEMS, a single
partition looks, acts, feels, sounds, smells, etc. like a traditional
RTEMS system.

Just my $0.02, adjusted for inflation...
-Bob

Charles Steaderman wrote:
> RFC
>
> Memory Partitioning Support in RTEMS
>
> Goals:
> Provide task level code and memory partitioning for RTEMS. The short
> term goal would be for a project that contains functionality to be FAA
> certified at different certification levels (background data
> collection and storage certified to FAA Level C, and user interface
> non-certified).
>
> Proposed Strategy:
> Based upon some research into commercial partitioned embedded OSes
> (Integrity, Nucleus Secure, etc), I would like to suggest the
> following strategy for enhancing RTEMS. First, to provide separation
> from the kernel, I would propose that all RTEMS kernel calls be
> accessed via a TRAP or SWI. In this way, the kernel code can be mapped
> into a non-accessable memory area in order to provide protection from
> userland tasks. Second, I would propose that task creation and context
> switching become memory region aware. Task creation would need to be
> supplied memory regions and access permissions and those permissions
> would need to be updated on a context switch (MMU registers). In
> addition, each task could have its own private memory heap for dynamic
> memory allocation. This would mean that memory allocation would need
> to be told whether the allocation should come from the local or global
> heap.
>
> I am sure that there is a large number of issues that I have
> overlooked, but I would like to get people thinking about partitioning
> in RTEMS. In much the same way that desktop operating systems have
> benefitted from process protectsion (Win9x vs. WinNT or OS 9 vs. OS
> X), I think that given the present and future state of embedded
> hardware, embedded systems could benefit from the same robustness. One
> advantage that I believe the proposed solution has is that the code
> resides in a single address space, rather than virtual memory spaces.
> Perhaps this will cause problems with library calls and shared code,
> but perhaps there is a novel solution that we could employ.
>
> Thank you for your time and consideration.
>
> - Charlie
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>