Some machines have specialized memories that are mapped in the
processor's address space just like ordinary RAM. For instance, some
high-performance machines feature low-latency scratchpad memories
used to speed up computations. Such memories, however, are seldom
properly exported by the operating system, requiring application
programs to directly handle them. The case of memory regions with
specific caching polices for parallel applications running on shared
memory machines, including contemporary multicore processors, fits
in the same scenario. A modern operating system could take advantage
of the fact that operator new() in C++ has two
signatures and override the so called placement new to
seamlessly export such memories. For example, application programmers
could write
Type * object = new Type;Type on the ordinary memory, and
Type * object = new (UNCACHED) Type;Split the application heap in two and implement the mechanism
illustrated above so that programmers will be able to allocate
memory that is cached on a write-back policy from one heap and
memory that is cached on a write-through policy from the other
one. The kmalloc() function shall no longer exist.
Hint: the heap on your current version of OpenEPOS is
declared in application.h, defined in
application_scaffold.cc (it's a static attribute), and
initialized in init_application.cc through the
invocation of MMU::alloc() to allocate memory for the
heap and Heap::free() to inject that memory into the
heap. A system abstraction called Segment does most of
what it takes to accomplish the task, but do not forget that
segments in EPOS designate memory regions and not address space
mappings. A Segment may exist, it may contain memory,
and yet it may be inaccessible because it was not attached (using
Address_Space::attach()) to any
Address_Space