1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/wiki/Roadmap Tue Dec 13 21:28:04 2022 +0100
1.3 @@ -0,0 +1,92 @@
1.4 += Roadmap =
1.5 +
1.6 +The development of a framework for demand-paged filesystem functionality is a
1.7 +potentially open-ended activity. Starting with an initial need to be able to
1.8 +read and write files from and to a storage medium, once features such as
1.9 +[[Paging|demand paging]] are introduced, the broader activity expands to
1.10 +encompass other exercises such as the implementation of a [[Program
1.11 +Loading|program loading]] mechanism.
1.12 +
1.13 +Some development priorities can nevertheless be identified. Here are some
1.14 +ideas and tentative plans.
1.15 +
1.16 +<<TableOfContents(2,2)>>
1.17 +
1.18 +== Program or Process Server ==
1.19 +
1.20 +The provision of a program server to initiate and monitor program execution
1.21 +would do much to support familiar operating system and language environment
1.22 +primitives, along the lines of `exec` and `spawn` operations found in similar
1.23 +systems.
1.24 +
1.25 +L4Re employs a "parent" interface to monitor program events, with a "signal"
1.26 +being sent upon program termination. This signal is sent by the C library
1.27 +implementation when the `main` function returns control to the C library. It
1.28 +seems worthwhile adopting this approach for compatibility with L4Re.
1.29 +
1.30 +== Library Loading Support ==
1.31 +
1.32 +Currently, the program loading functionality does not support dynamic
1.33 +library loading.
1.34 +
1.35 +== Test Sequencing and Shell Functionality ==
1.36 +
1.37 +Currently, testing attempts to validate the behaviour of various operations
1.38 +within individual programs, but this involves a fair amount of repetitive
1.39 +work. Meanwhile, the `fsaccess` program offers a simple way of performing
1.40 +filesystem operations resembling that of a shell, but it does not offer the
1.41 +kind of sophisticated shell functionality that would help in assessing whether
1.42 +operations behave as expected.
1.43 +
1.44 +If proper program or process monitoring were to be supported, a very simple
1.45 +shell could be implemented, this being able to run arbitrary programs instead
1.46 +of a small selection of operations. A more natural Unix-like approach could
1.47 +then be taken, with tests implemented by individual programs, and with such
1.48 +programs being combined to assess test output. To facilitate this, support for
1.49 +providing input and output streams to processes would also be required.
1.50 +
1.51 +== C Library Support ==
1.52 +
1.53 +The previous iteration of this general effort introduced a new C library based
1.54 +on Newlib that employed the filesystem access framework. It seems likely that
1.55 +a similar approach will be taken for this iteration as well.
1.56 +
1.57 +== Virtual Filesystems ==
1.58 +
1.59 +The previous iteration of this work provided a virtual filesystem server that
1.60 +could combine different filesystems, permitting them to be mounted into the
1.61 +same hierarchy. L4Re seems to attempt this using its namespace concept, but
1.62 +this results in a kind of discontinuity between the namespaces hosting the
1.63 +filesystem "mountpoints" and the mounted filesystems themselves, at least in
1.64 +terms of the metadata supported by the two types of naming hierarchies.
1.65 +Namespaces appear to behave only superficially as directories when treated as
1.66 +such.
1.67 +
1.68 +One approach might involve replicating a traditional Unix approach, with a
1.69 +base filesystem provided by a conventional filesystem implementation, and with
1.70 +mounted filesystems residing at mountpoints within that filesystem. This would
1.71 +have the benefit of supporting access controls using the metadata in the root
1.72 +filesystem. If a block device were provided via the filesystem, then the
1.73 +ability to mount it should be restricted according to that device's
1.74 +access-related metadata.
1.75 +
1.76 +It should still be possible to complement this approach with a way of binding
1.77 +filesystems to arbitrary locations for a given program. This would permit
1.78 +programs to access devices or services for which they have access
1.79 +independently of any privilege hierarchy defined by the system. For example, a
1.80 +program operated by a user may be able to authenticate itself to access a
1.81 +remote service, and such authentication and associated privileges would be
1.82 +orthogonal to those defined by the local system.
1.83 +
1.84 +== Monitoring Facilities ==
1.85 +
1.86 +It would be useful to be able to monitor various components so as to get an
1.87 +idea of their behaviour and how well they perform. A filesystem's registry of
1.88 +open files could be exposed through some kind of control interface, as could
1.89 +the regions of individual files that are currently held in memory. A process
1.90 +or program server could expose its registry of processes similarly.
1.91 +
1.92 +Although it might not necessarily be desirable for some kinds of systems to
1.93 +have centralised registries of things like files and processes, exposed
1.94 +through the provision of utilities like `lsof` and `ps`, selective access to
1.95 +individual registries of information would still be helpful.