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 Currently, a process server is implemented, but more control over the 28 configuration of individual processes is desirable. It should be possible to 29 run programs that cannot access the filesystem from which they were loaded, 30 instead accessing a different, user-supplied filesystem. 31 32 == Library Loading Support == 33 34 Currently, the program loading functionality does not support dynamic 35 library loading. 36 37 == Program Environment Support == 38 39 The program loading functionality does relatively little beyond the 40 initialisation of an initial environment that can start a program. Work is 41 needed to handle situations like the exhaustion of the program stack and to be 42 able to extend the stack appropriately. 43 44 == Test Sequencing and Shell Functionality == 45 46 Currently, testing attempts to validate the behaviour of various operations 47 within individual programs, but this involves a fair amount of repetitive 48 work. Meanwhile, the `fsaccess` program offers a simple way of performing 49 filesystem operations resembling that of a shell, but it does not offer the 50 kind of sophisticated shell functionality that would help in assessing whether 51 operations behave as expected. 52 53 If proper program or process monitoring were to be supported, a very simple 54 shell could be implemented, this being able to run arbitrary programs instead 55 of a small selection of operations. A more natural Unix-like approach could 56 then be taken, with tests implemented by individual programs, and with such 57 programs being combined to assess test output. To facilitate this, support for 58 providing input and output streams to processes would also be required. 59 60 == C Library Support == 61 62 The previous iteration of this general effort introduced a new C library based 63 on Newlib that employed the filesystem access framework. It seems likely that 64 a similar approach will be taken for this iteration as well. 65 66 The C library should provide support for all the elements of the frameworks 67 implemented in this project, and it should also provide usable threading 68 mechanisms. 69 70 == Virtual Filesystems == 71 72 The previous iteration of this work provided a virtual filesystem server that 73 could combine different filesystems, permitting them to be mounted into the 74 same hierarchy. L4Re seems to attempt this using its namespace concept, but 75 this results in a kind of discontinuity between the namespaces hosting the 76 filesystem "mountpoints" and the mounted filesystems themselves, at least in 77 terms of the metadata supported by the two types of naming hierarchies. 78 Namespaces appear to behave only superficially as directories when treated as 79 such. 80 81 One approach might involve replicating a traditional Unix approach, with a 82 base filesystem provided by a conventional filesystem implementation, and with 83 mounted filesystems residing at mountpoints within that filesystem. This would 84 have the benefit of supporting access controls using the metadata in the root 85 filesystem. If a block device were provided via the filesystem, then the 86 ability to mount it should be restricted according to that device's 87 access-related metadata. 88 89 It should still be possible to complement this approach with a way of binding 90 filesystems to arbitrary locations for a given program. This would permit 91 programs to access devices or services for which they have access 92 independently of any privilege hierarchy defined by the system. For example, a 93 program operated by a user may be able to authenticate itself to access a 94 remote service, and such authentication and associated privileges would be 95 orthogonal to those defined by the local system. 96 97 == Monitoring Facilities == 98 99 It would be useful to be able to monitor various components so as to get an 100 idea of their behaviour and how well they perform. A filesystem's registry of 101 open files could be exposed through some kind of control interface, as could 102 the regions of individual files that are currently held in memory. A process 103 or program server could expose its registry of processes similarly. 104 105 Although it might not necessarily be desirable for some kinds of systems to 106 have centralised registries of things like files and processes, exposed 107 through the provision of utilities like `lsof` and `ps`, selective access to 108 individual registries of information would still be helpful.