# HG changeset patch # User Paul Boddie # Date 1681045325 -7200 # Node ID 40e889c0788f6744076d34ca7fba2cc25aee8cb3 # Parent 542bf2c53298f7169269ab1e21caca8bb37f2861 Updated program loading and roadmap notes. diff -r 542bf2c53298 -r 40e889c0788f docs/wiki/Program_Loading --- a/docs/wiki/Program_Loading Fri Apr 07 23:35:21 2023 +0200 +++ b/docs/wiki/Program_Loading Sun Apr 09 15:02:05 2023 +0200 @@ -215,7 +215,7 @@ IPCGate_note -> IPCGate [dir=none,style=dotted]; } - InitCaps [shape=record,label=" Initial capabilities | { \"server\" | capability }"]; + InitCaps [shape=record,label=" Initial capabilities | { ENV_INTERNAL_PAGER_NAME | capability }"]; subgraph { rank=same; @@ -248,3 +248,27 @@ }}} ######## + +The creating task performs the following operations: + + 1. Create an IPC gate for communication between the program and its pager. + + 1. Map the IPC gate into the created task to be accessible via a given + capability slot. + + 1. Define the IPC gate in the pager's initial capabilities using a + well-defined name, allowing the pager to look up the capability in its + environment. + + 1. Start the pager which itself obtains the IPC gate capability and binds to + it, making itself available as the pager for the program. + + 1. Set the pager of the program to the IPC gate as mapped within the task. + + 1. Start the program which is already configured to send page faults via the + IPC gate to the pager. + +Upon starting, the program will encounter a page fault immediately, unless +some additional work was done to map memory pages into the task in advance. +The internal pager or page fault handler will attempt to resolve these faults +as they occur, being contacted by the kernel on the program's behalf. diff -r 542bf2c53298 -r 40e889c0788f docs/wiki/Roadmap --- a/docs/wiki/Roadmap Fri Apr 07 23:35:21 2023 +0200 +++ b/docs/wiki/Roadmap Sun Apr 09 15:02:05 2023 +0200 @@ -24,11 +24,23 @@ implementation when the `main` function returns control to the C library. It seems worthwhile adopting this approach for compatibility with L4Re. +Currently, a process server is implemented, but more control over the +configuration of individual processes is desirable. It should be possible to +run programs that cannot access the filesystem from which they were loaded, +instead accessing a different, user-supplied filesystem. + == Library Loading Support == Currently, the program loading functionality does not support dynamic library loading. +== Program Environment Support == + +The program loading functionality does relatively little beyond the +initialisation of an initial environment that can start a program. Work is +needed to handle situations like the exhaustion of the program stack and to be +able to extend the stack appropriately. + == Test Sequencing and Shell Functionality == Currently, testing attempts to validate the behaviour of various operations @@ -51,6 +63,10 @@ on Newlib that employed the filesystem access framework. It seems likely that a similar approach will be taken for this iteration as well. +The C library should provide support for all the elements of the frameworks +implemented in this project, and it should also provide usable threading +mechanisms. + == Virtual Filesystems == The previous iteration of this work provided a virtual filesystem server that