The development of a framework for demand-paged filesystem functionality is a potentially open-ended activity. Starting with an initial need to be able to read and write files from and to a storage medium, once features such as demand paging are introduced, the broader activity expands to encompass other exercises such as the implementation of a program loading mechanism.
Some development priorities can nevertheless be identified. Here are some ideas and tentative plans.
The provision of a program server to initiate and monitor program execution would do much to support familiar operating system and language environment primitives, along the lines of exec and spawn operations found in similar systems.
L4Re employs a "parent" interface to monitor program events, with a "signal" being sent upon program termination. This signal is sent by the C library 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.
Currently, the program loading functionality does not support dynamic library loading.
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.
Currently, testing attempts to validate the behaviour of various operations within individual programs, but this involves a fair amount of repetitive work. Meanwhile, the fsaccess program offers a simple way of performing filesystem operations resembling that of a shell, but it does not offer the kind of sophisticated shell functionality that would help in assessing whether operations behave as expected.
If proper program or process monitoring were to be supported, a very simple shell could be implemented, this being able to run arbitrary programs instead of a small selection of operations. A more natural Unix-like approach could then be taken, with tests implemented by individual programs, and with such programs being combined to assess test output. To facilitate this, support for providing input and output streams to processes would also be required.
The previous iteration of this general effort introduced a new C library based 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.
The previous iteration of this work provided a virtual filesystem server that could combine different filesystems, permitting them to be mounted into the same hierarchy. L4Re seems to attempt this using its namespace concept, but this results in a kind of discontinuity between the namespaces hosting the filesystem "mountpoints" and the mounted filesystems themselves, at least in terms of the metadata supported by the two types of naming hierarchies. Namespaces appear to behave only superficially as directories when treated as such.
One approach might involve replicating a traditional Unix approach, with a base filesystem provided by a conventional filesystem implementation, and with mounted filesystems residing at mountpoints within that filesystem. This would have the benefit of supporting access controls using the metadata in the root filesystem. If a block device were provided via the filesystem, then the ability to mount it should be restricted according to that device's access-related metadata.
It should still be possible to complement this approach with a way of binding filesystems to arbitrary locations for a given program. This would permit programs to access devices or services for which they have access independently of any privilege hierarchy defined by the system. For example, a program operated by a user may be able to authenticate itself to access a remote service, and such authentication and associated privileges would be orthogonal to those defined by the local system.
It would be useful to be able to monitor various components so as to get an idea of their behaviour and how well they perform. A filesystem's registry of open files could be exposed through some kind of control interface, as could the regions of individual files that are currently held in memory. A process or program server could expose its registry of processes similarly.
Although it might not necessarily be desirable for some kinds of systems to have centralised registries of things like files and processes, exposed through the provision of utilities like lsof and ps, selective access to individual registries of information would still be helpful.