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