= Roadmap =

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

[[Paging|demand paging]] are introduced, the broader activity expands to

encompass other exercises such as the implementation of a [[Program

Loading|program loading]] mechanism.

Some development priorities can nevertheless be identified. Here are some

ideas and tentative plans.

<<TableOfContents(2,2)>>

== Program or Process Server ==

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.

== Library Loading Support ==

Currently, the program loading functionality does not support dynamic

library loading.

== Test Sequencing and Shell Functionality ==

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.

== C Library Support ==

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.

== Virtual Filesystems ==

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.

== Monitoring Facilities ==

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.