NEWPHORIA

Nostromo Component: Micro Kernel Module (microkernel, MIKM)

This module provides the micro kernel, covering only the most basic of functionalities. This API is exposed internally as "MIKM_"-prefixed functions. The functions are executed in system land where possible and applicable. Userland code may not access functions that are systemland-only. Note that a device handle is still valid after a device is physically removed from the system. Operations on a physically removed device will resume once the device is reattached. (This also means that a device connected to a different USB port, for instance is still recognized as the same device; this requires internal device abstraction and naming concepts to be defined further.)

• Lowest Level Functionality
  • KernelDebugger(): Low-level console and/or serial line driven debugger. If the kernel discovers a non-recoverable problem, it may fall back into the kernel debugger. The user can control the system and diagnose the problem.
  • Doubly-Linked List functions: These functions have to be at this place because they're used by many parts of the kernel. A separate module might provide additional containers.
    • InitNode(): Initializes a node before usage.
    • LinkNode(): Links a node between two other nodes.
    • RemNode(): Remove the link between a node and its surrounding nodes.
    • InitList(): Initializes a list before usage. After initialization, the list consists of a separate head and tail node, pointing to each other. The head and tail nodes are not intended to be accessible, they're only used for internal bookkeeping.
    • AddHead(): Adds a node at the head of the list.
    • AddTail(): Adds a node at the tail of the list.
    • RemHead(): Removes a node at the head of the list. Returns 0 if list is empty.
    • RemTail(): Removes a node at the tail of the list. Returns 0 if list is empty.
    • FirstNode(): Returns the first node of the list (the node following the head node). Returns 0 if list is empty.
    • LastNode(): Returns the last node of the list (the node following the tail node). Returns 0 if list is empty.
    • NextNode(): Returns the next node in the list (the node following the specified node). Returns 0 if list is empty.
    • PrevNode(): Returns the previous node in the list (the node preceding the specified node). Returns 0 if list is empty.
    • ListEmpty(): Returns a boolean indicator to indicate if the list is empty.
    • ScanList(): Callback mechanism to scan through a list.
  • Kernel Locking:
    • LockKernel(): Locks kernel data structures.
    • UnlockKernel(): Unlocks kernel data structures.
  • Reset and Shutdown Functionality:
    • ColdReset(): Resets the machine.
    • ColdHalt(): Stops the machine.
• System Initialization
  • InitMicroKernel(): This initializes the micro kernel.
  • InitDevices(): for systems with a host BIOS (PC, CHRP) that MUST be used, during early startup stages; optional for Amiga (if in ROM)
  • InitDevices(): Amiga ROMs only version
  • These functions scan for pieces of well-known low-level hardware and initializes them. They're added to an internal device list. Device initialization also initializes interrupts, memory, CPUs, etc.
• Interrupt Management
  • AddInterrupt(): Adds an interrupt or exception handler.
  • RemInterrupt(): Removes an interrupt or exception handler.
• Device Management
  • AddDevice(): Adds a device to the system.
  • RemDevice(): Removes a device from the system.
  • LockDevice(): Locks a device for using it.
  • UnlockDevice(): Unlocks a device.
• Kernel Task Management: These functions are internal convenience APIs to simplify the setup and maintenance of kernel tasks. The implementation is covered by a CPU device handler.
  • AddKernelTask(): Adds another kernel task to the list of tasks maintained by each CPU.
  • RemKernelTask(): Removes a kernel task.
  • LockKernelTask(): Locks a kernel task to prevent it from running.
  • UnlockKernelTask(): Unlocks a kernel task.
  • ScheduleKernelTask(): Schedule a kernel task to be run on the calling CPU.
  • NextKernelTask(): Schedules the next available kernel task on the calling CPU.
  • AddKTInterrupt(): Adds an interrupt or exception handler to a kernel task.
  • RemKTInterrupt(): Removes interrupt or exception handler from a kernel task.
  • AddKTMem(): Adds memory to a kernel task.
  • RemKTMem(): Removes memory from a kernel task.
  • Note: Memory must be obtained from a memory device handler that is suitable for the CPU.
• Kernel Task Communication
  • GetKernelMsg(): Retrieves the next kernel message in the queue of the current kernel task.
  • PutKernelMsg(): Puts a kernel message to a kernel task. This might involve copying.

Nostromo Component: Macro Kernel Module (macrokernel, MAKM):

The MAKM provides a level of abstraction one level higher than the MIKM. It is intended to provide Light Weight Processes (LWP), which are used further to provide basic thread and process capabilities. MAKM functions are prefixed with "MAKM_" and are normally run in systemland context.

• System Initialization
  • InitMacroKernel(): Initializes the macro kernel.
• Light-Weight Process Management: This serves as an abstraction to kernel tasks (which run only on designated CPUs). Lightweight Processes are automatically scheduled on suitable CPUs.
  • AddLWP(): Adds a new lightweight process.
  • RemLWP(): Removes a lightweight process.
  • SchedLWP(): Schedules a light weight process on any suitable CPU.
  • NextLWP(): Schedules the next logical light weight process.
• "Heavy"-Weight Thread and Process Management: So-called "heavy"-weight threads and processes are what most OSes understand in terms of threads and processes, except that at the macro kernel level, they're just a further abstraction of LWPs. They provide the specific semantics expected of threads and processes. Note that signalling is similar to POSIX signals. Signals are handled immediately and are implemented in terms of software interrupts.
  • AddThread(): Adds a new thread to the current process.
  • RemThread(): Removes a thread from the current process.
  • AddProcess(): Adds a new process to the system.
  • RemProcess(): Removes a process from the system.
  • AddSignalHandler(): Adds a handler for a specific signal to a thread.
  • RemSignalHandler(): Removes a signal handler from a thread.
  • DeliverSignal(): Delivers a signal to a thread.
  • GetThreadId(): Retrieves the current thread id.
  • GetProcessId(): Retrieves the current process id.
• Heavy-Weight Thread and Process Communication: Messages may be sent between threads. Messages are automatically copied where necessary.
  • PostMessage(): Post a message to a thread.
  • NextMessage(): Retrieves the next message for the current thread.
  • WaitMessage(): Waits for any message to arrive or terminates immediately if there are available messages.
• Memory Mapping: Provides memory mapping facilities that can be used by memory allocation and deallocation services. Also facilitates virtual memory through memory handlers.
  • MapMemory(): Maps memory into the address space of the calling process or thread (process-local or thread-local memory). Also reserves memory for usage with guarding techniques.
  • UnmapMemory(): Unmaps memory.
  • AddMemHandler(): Adds a memory handler to a chunk of memory.
  • RemMemHandler(): Removes a memory handler.

Nostromo Component: User Kernel Module (userkernel, UKM):

The user kernel is what is perceived as a userland kernel module. Its functions are prefixed with UKM_ and can be called from other userland kernel code. UKM abstraction of system-land services are provided through specialized APIs of same name.

UKM also provides abstraction of various concepts which save the programmer from talking to device handlers or system-land code directly.

• Initialization
  • InitUserKernel(): Initializes the user kernel.
• Memory Management:
  • AllocateMemory(): Allocate a chunk of memory.
  • DeallocateMemory(): Deallocate a chunk of memory.
• File System Management: Filing systems for Nostromo must be capable of self-repair. When a volume is mounted for a particular file system, it should automatically be tested for obvious errors. During operation, if an inconsistency of the file system is detected, a background process shall be run that begins repairs, and the caller is to be put on hold while the operation runs. Once the repair is complete, the control is returned to the caller. An error is returned only if it is truly unrecoverable.
  • AddFileSystem(): Adds a new file system type (not mount point) to the system.
  • RemFileSystem(): Removes a file system type from the system.
  • LockFileSystem(): Locks a file system type while it is being used.
  • UnlockFileSystem(): Unlocks a file system type after use.
  • MountVolume(): Mounts a volume on the specified device. The file system is determined automatically.
  • UnmountVolume(): Unmounts a volume on the specified device.
  • EjectVolume(): Ejects the current volume on the specified device, if supported.
  • OpenFile(): Opens a file on the specified volume. Only full path names are accepted. Paths follow URI notation, and begin with a volume designator. As in "work://office/paper1". Note that this notation is used only in the UKM. Other abstractions might require a different path notation.
  • CloseFile(): Closes a file.
  • ReadFile(): Reads from a file.
  • WriteFile(): Writes to a file.
  • SeekFile(): Seeks within a file.
  • RemoveFile(): Removes a file.
  • LockFile(): Locks a portion of a file, or an entire file.
  • UnlockFile(): Unlocks a portion of a file, or an entire file.
• Network Management (TBD)
• Display Monitor Management: Manages display devices like monitors. Provides access to bitmapped graphics display and text display.
  • AddMonitor(): Adds a display monitor to the system.
  • RemMonitor(): Removes a display monitor from the system.
  • LockMonitor(): Locks a display monitor for use.
  • UnlockMonitor(): Unlocks a display monitor after use.
• Keyboard Management: Manages keyboard-like input devices.
  • AddKeyboard(): Adds a keyboard to the system.
  • RemKeyboard(): Removes a keyboard from the system.
  • LockKeyboard(): Locks a keyboard for use.
  • UnlockKeyboard(): Unlocks a keyboard after use.
• Mouse Management: Manages mouse-like input devices.
  • AddMouse(): Adds a new mouse to the system.
  • RemMouse(): Removes a mouse from the system.
  • LockMouse(): Locks a mouse for usage.
  • UnlockMouse(): Unlocks a mouse after use.
• Timer Management: Manages timer-like devices.
  • AddTimer(): Adds a new timer to the system.
  • RemTimer(): Removes a timer from the system.
  • LockTimer(): Locks a timer for use.
  • UnlockTimer(): Unlocks a timer after use.
• CUI Management: This is for managing console user interfaces (CUI). It encapsulates access to monitors and keyboards (and mice, where available).
  • AddConsole(): Adds a new console to the system.
  • RemConsole(): Removes a console from the system.
  • LockConsole(): Locks a console for usage.
  • UnlockConsole(): Unlocks a console after use.
  • ReadConsole(): Reads from a console.
  • WriteConsole(): Writes to a console.
• GUI Management: This is for managing graphical user interfaces (GUI). It encapsulates access to monitors and keyboards (and mice, where available).
  • AddGUI(): Adds a new GUI to the system.
  • RemGUI(): Removes a GUI from the system.
  • LockGUI(): Locks a GUI for usage.
  • UnlockGUI(): Unlocks a GUI after use.
  • ReadGUI(): Reads from a GUI.
  • WriteGUI(): Writes to a GUI.

Nostromo Component: User System Module (usersystem, USM):

The USM handles multiple concurrent users on the same machine, and other yet-to-be-defined things. It runs in userland.

• Inititialization
  • InitUserSystem(): Initializes USM.
• Concurrent User Management:
  • CCAddUser(): Adds a new user to the system.
  • CCRemUser(): Removes a user from the system.
  • CCLockUser(): Locks user when logged in.
  • CCUnlockUser(): Unlocks user after logout.

Nostromo Component: User API Module (userapi, UAM):

Finally, UAM provides what would pass for a system API in other operating systems. It can be used by applications running at UAM level. Those are considered low-level on DELOS, but can provide early or high-speed usability, while the remaining system is under further consideration. UAM functions run in userland and are prefixed with "UAM_".

Specification has to be done.