| paul@471 | 1 | = Roadmap = |
| paul@471 | 2 | |
| paul@471 | 3 | The development of a framework for demand-paged filesystem functionality is a |
| paul@471 | 4 | potentially open-ended activity. Starting with an initial need to be able to |
| paul@471 | 5 | read and write files from and to a storage medium, once features such as |
| paul@471 | 6 | [[Paging|demand paging]] are introduced, the broader activity expands to |
| paul@471 | 7 | encompass other exercises such as the implementation of a [[Program |
| paul@471 | 8 | Loading|program loading]] mechanism. |
| paul@471 | 9 | |
| paul@471 | 10 | Some development priorities can nevertheless be identified. Here are some |
| paul@471 | 11 | ideas and tentative plans. |
| paul@471 | 12 | |
| paul@471 | 13 | <<TableOfContents(2,2)>> |
| paul@471 | 14 | |
| paul@471 | 15 | == Program or Process Server == |
| paul@471 | 16 | |
| paul@471 | 17 | The provision of a program server to initiate and monitor program execution |
| paul@471 | 18 | would do much to support familiar operating system and language environment |
| paul@471 | 19 | primitives, along the lines of `exec` and `spawn` operations found in similar |
| paul@471 | 20 | systems. |
| paul@471 | 21 | |
| paul@471 | 22 | L4Re employs a "parent" interface to monitor program events, with a "signal" |
| paul@471 | 23 | being sent upon program termination. This signal is sent by the C library |
| paul@471 | 24 | implementation when the `main` function returns control to the C library. It |
| paul@471 | 25 | seems worthwhile adopting this approach for compatibility with L4Re. |
| paul@471 | 26 | |
| paul@568 | 27 | Currently, a process server is implemented, but more control over the |
| paul@568 | 28 | configuration of individual processes is desirable. It should be possible to |
| paul@568 | 29 | run programs that cannot access the filesystem from which they were loaded, |
| paul@568 | 30 | instead accessing a different, user-supplied filesystem. |
| paul@568 | 31 | |
| paul@471 | 32 | == Library Loading Support == |
| paul@471 | 33 | |
| paul@471 | 34 | Currently, the program loading functionality does not support dynamic |
| paul@471 | 35 | library loading. |
| paul@471 | 36 | |
| paul@568 | 37 | == Program Environment Support == |
| paul@568 | 38 | |
| paul@568 | 39 | The program loading functionality does relatively little beyond the |
| paul@568 | 40 | initialisation of an initial environment that can start a program. Work is |
| paul@568 | 41 | needed to handle situations like the exhaustion of the program stack and to be |
| paul@568 | 42 | able to extend the stack appropriately. |
| paul@568 | 43 | |
| paul@471 | 44 | == Test Sequencing and Shell Functionality == |
| paul@471 | 45 | |
| paul@471 | 46 | Currently, testing attempts to validate the behaviour of various operations |
| paul@471 | 47 | within individual programs, but this involves a fair amount of repetitive |
| paul@471 | 48 | work. Meanwhile, the `fsaccess` program offers a simple way of performing |
| paul@471 | 49 | filesystem operations resembling that of a shell, but it does not offer the |
| paul@471 | 50 | kind of sophisticated shell functionality that would help in assessing whether |
| paul@471 | 51 | operations behave as expected. |
| paul@471 | 52 | |
| paul@471 | 53 | If proper program or process monitoring were to be supported, a very simple |
| paul@471 | 54 | shell could be implemented, this being able to run arbitrary programs instead |
| paul@471 | 55 | of a small selection of operations. A more natural Unix-like approach could |
| paul@471 | 56 | then be taken, with tests implemented by individual programs, and with such |
| paul@471 | 57 | programs being combined to assess test output. To facilitate this, support for |
| paul@471 | 58 | providing input and output streams to processes would also be required. |
| paul@471 | 59 | |
| paul@471 | 60 | == C Library Support == |
| paul@471 | 61 | |
| paul@471 | 62 | The previous iteration of this general effort introduced a new C library based |
| paul@471 | 63 | on Newlib that employed the filesystem access framework. It seems likely that |
| paul@471 | 64 | a similar approach will be taken for this iteration as well. |
| paul@471 | 65 | |
| paul@568 | 66 | The C library should provide support for all the elements of the frameworks |
| paul@568 | 67 | implemented in this project, and it should also provide usable threading |
| paul@568 | 68 | mechanisms. |
| paul@568 | 69 | |
| paul@471 | 70 | == Virtual Filesystems == |
| paul@471 | 71 | |
| paul@471 | 72 | The previous iteration of this work provided a virtual filesystem server that |
| paul@471 | 73 | could combine different filesystems, permitting them to be mounted into the |
| paul@471 | 74 | same hierarchy. L4Re seems to attempt this using its namespace concept, but |
| paul@471 | 75 | this results in a kind of discontinuity between the namespaces hosting the |
| paul@471 | 76 | filesystem "mountpoints" and the mounted filesystems themselves, at least in |
| paul@471 | 77 | terms of the metadata supported by the two types of naming hierarchies. |
| paul@471 | 78 | Namespaces appear to behave only superficially as directories when treated as |
| paul@471 | 79 | such. |
| paul@471 | 80 | |
| paul@471 | 81 | One approach might involve replicating a traditional Unix approach, with a |
| paul@471 | 82 | base filesystem provided by a conventional filesystem implementation, and with |
| paul@471 | 83 | mounted filesystems residing at mountpoints within that filesystem. This would |
| paul@471 | 84 | have the benefit of supporting access controls using the metadata in the root |
| paul@471 | 85 | filesystem. If a block device were provided via the filesystem, then the |
| paul@471 | 86 | ability to mount it should be restricted according to that device's |
| paul@471 | 87 | access-related metadata. |
| paul@471 | 88 | |
| paul@471 | 89 | It should still be possible to complement this approach with a way of binding |
| paul@471 | 90 | filesystems to arbitrary locations for a given program. This would permit |
| paul@471 | 91 | programs to access devices or services for which they have access |
| paul@471 | 92 | independently of any privilege hierarchy defined by the system. For example, a |
| paul@471 | 93 | program operated by a user may be able to authenticate itself to access a |
| paul@471 | 94 | remote service, and such authentication and associated privileges would be |
| paul@471 | 95 | orthogonal to those defined by the local system. |
| paul@471 | 96 | |
| paul@471 | 97 | == Monitoring Facilities == |
| paul@471 | 98 | |
| paul@471 | 99 | It would be useful to be able to monitor various components so as to get an |
| paul@471 | 100 | idea of their behaviour and how well they perform. A filesystem's registry of |
| paul@471 | 101 | open files could be exposed through some kind of control interface, as could |
| paul@471 | 102 | the regions of individual files that are currently held in memory. A process |
| paul@471 | 103 | or program server could expose its registry of processes similarly. |
| paul@471 | 104 | |
| paul@471 | 105 | Although it might not necessarily be desirable for some kinds of systems to |
| paul@471 | 106 | have centralised registries of things like files and processes, exposed |
| paul@471 | 107 | through the provision of utilities like `lsof` and `ps`, selective access to |
| paul@471 | 108 | individual registries of information would still be helpful. |
