# HG changeset patch # User Paul Boddie # Date 1670963284 -3600 # Node ID c735e5869ff4a55d7bba7a5454fba166a901c4de # Parent 768bb7469370e592163cc9bd762e322d0352a352 Added some more generally useful information. diff -r 768bb7469370 -r c735e5869ff4 docs/wiki/Departure --- a/docs/wiki/Departure Tue Dec 13 17:06:16 2022 +0100 +++ b/docs/wiki/Departure Tue Dec 13 21:28:04 2022 +0100 @@ -1,5 +1,7 @@ = Departure = +|| [[Getting Started]] || [[Downloads]] || [[Roadmap]] || + The Departure distribution aims to provide components and libraries to implement and deliver filesystem access in the L4 Runtime Environment. In particular, it acts as a research and testing vehicle for implementations of @@ -74,6 +76,8 @@ * [[Users]] -Project organisation: +Project organisation and development topics: + * [[Downloads]] * [[Libraries]] + * [[Roadmap]] diff -r 768bb7469370 -r c735e5869ff4 docs/wiki/Downloads --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/wiki/Downloads Tue Dec 13 21:28:04 2022 +0100 @@ -0,0 +1,32 @@ += Downloads = + +Remember that certain [[../Prerequisites|prerequisites]] are needed for the +software to work. + +== Copyright and Licence == + +The Departure distribution is made available according to the terms of the +[[http://www.gnu.org/copyleft/gpl.html|GPL]] version 2 or later. See +the `docs/COPYING.txt` and `docs/LICENCE.txt` files in the source code +distribution for details. + +== Repository == + +The source code repository is located at the following location: + +[[https://hg.boddie.org.uk/L4Re/departure]] + +The repository can be cloned using [[https://www.mercurial-scm.org/|Mercurial]] +as follows: + +{{{ +hg clone https://hg.boddie.org.uk/L4Re/departure +}}} + +If you are familiar with version control systems and Mercurial in particular, +it can be convenient to use this approach to obtain and update the software, +although you should be aware that updates made available in the repository may, +if deployed, cause the software to not function correctly on occasion, even if +attempts are made to avoid such situations. Therefore, you should choose to +update with care and be prepared to switch to a "known working" revision if +necessary. diff -r 768bb7469370 -r c735e5869ff4 docs/wiki/Prerequisites --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/wiki/Prerequisites Tue Dec 13 21:28:04 2022 +0100 @@ -0,0 +1,18 @@ += Prerequisites = + +Departure has the following general dependencies or prerequisites: + +{{{#!table +'''Prerequisite''' || '''Suggestions''' +== +Basic development tools +(for building the software) || Debian package: build-essential +== +idl4re || [[https://projects.boddie.org.uk/idl4re]] +== +L4Re +(to apply this software) || See [[https://github.com/kernkonzept/manifest/wiki]] +== +MoinLight +(needed for documentation) || [[https://projects.boddie.org.uk/MoinLight]] +}}} diff -r 768bb7469370 -r c735e5869ff4 docs/wiki/Roadmap --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/wiki/Roadmap Tue Dec 13 21:28:04 2022 +0100 @@ -0,0 +1,92 @@ += 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. + +<> + +== 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.