CoreLinux++ Functional Requirement Document
Revision $Revision: 1.3 $
Last Modified : Tuesday, April 11, 2000

Title : Memory

Requirement ID: 20873
Analysis References: Use Case Report , Analysis Diagrams
Design References: Class Report , Design Diagrams
Cross References:

1. Introduction

Memory is high speed transient storage managed by the operating system, for both itself and user processes, used to store data and programs.

Upon allocation request, the operating system provides user processes with a memory storage region that is in addition to the current memory resources (stack, program, data) of the process. The memory can be made visible to all processes in the system, a select few, or just to the process that requested the storage. If made visible to other processes, memory provides a fast and efficient way to transfer information between the processes, and in this manner can be catagorized as high speed interprocess communication. It is up to the processes that share this memory area to agree on a synchronization protocol.

The operating system allows a process to "mark" a memory region attribute as:

1. Read only

   Memory marked with this attribute restrict processes to read only operations performed on the memory storage region. Attempts to write anything to this area will result in a system exception.

2. Read/Write

   Marked as Read/Write, processes have the ability to store and retrieve from the memory storage region. This is the most common form of access.

3. Executable

   This marks a memory region in the memory storage region as executable. This provides a convenient way for user processes to load dynamic program blocks for execution. By definition, memory in a region marked executable is readable and writeable.

1.1 Deliverables Overview

Objective

The main deliverable objective is to provide utility for the allocation, management, and deallocation of memory storage in a user application. This fundementaly includes supporting various size, access, and visibiltiy controls over the allocated memory storage area. In addition, to provide flexebility and extendability for the control and management of memory, thereby supporting solution domain requirements.

A secondary objective is to provide MemoryStorage, a first class object the encapsulates the specific location of memory by defining access primitives as well as functor and iteration primitives.

2. Functional Requirements

Memory Utility Requirements

1. The CoreLinux++ Memory implementation shall provide support for creating private memory storage.

2. The CoreLinux++ Memory implementation shall provide support for creating public memory storage.

3. The CoreLinux++ Memory implementation shall provide support for attaching public memory storage from different processes.

4. The CoreLinux++ Memory implementation shall provide support for resizing of private memory storage.

5. The CoreLinux++ Memory implementation shall provide support for controlling access permissions to memory storage.

6. The CoreLinux++ Memory implementation shall provide support for controlling the read/write/executable attributes of memory storage.

7. The CoreLinux++ Memory implementation shall provide support for destroying memory storage.

8. The CoreLinux++ Memory implementation shall provide support for detaching public memory storage from different processes.

9. The CoreLinux++ Memory implementation shall provide instrumentation on allocation and deallocation requests.

MemoryStorage Requirements

1. The CoreLinux++ MemoryStorage implementation shall provide synchronous read and write primitives.

2. The CoreLinux++ MemoryStorage implementation shall provide functor support.

3. The CoreLinux++ MemoryStorage implementation shall provide iteration primitives.

2.1 User Interface Specifications

NA

2.2 Product Services

NA

2.3 External Interfaces and Database Requirements

NA

2.4 Error Handling

2.5 Foreseeable Functional Changes and Enhancements

3. Non-Functional Requirements

3.1 Performance Requirements

3.2 User Documentation and Other User Aids

Use Case, Analysis, Design, and Class Reference documentation.

3.3 Development Requirements

Standards: CoreLinux++ C++ Standards and Guidelines

3.4 Foreseeable Non-Functional Changes

TBD

4. Remarks and Guidelines for Later Life Cycle Phases

TBD

5. Term Glossary