[RFC] Filesystem experiments #197
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This will provide a better user interface to manipulate files (closer to Ada.Text_IO) than the one required for filesystem drivers. This idea comes from the difficulty to have an good interface that covers both the filesystem drivers where implementation have to define their own file handles and a clean user file IO API. This separation also makes sense when looking at operating systems. For instance on Linux, there's a difference between the user interface (usually the C library) and the filesystem driver implementation (super block, inodes, etc.). This is an incomplete experimental version.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this pull request I try two independent experiments on filesystem and path representation.
First the interface. We realized in the past that it's difficult to have a good file-system driver interface (HAL.Filesystem) in particular with regards to the handling of handles and their deallocation (#68).
The idea I’m trying here is to have a front-end interface (File IO) and a backend (filesystem driver), pretty much like any operating system would do.
The front-end interface would be similar to Ada.Text_IO or GNAT.OS_Lib. Unfortunately it probably won't be possible to use standard Ada.Text_IO* because they rely a lot on exception which are not always available or desirable in our case.
Having this separation between file operations and FS drivers allows:
The back-end would look like the current HAL.Filesystem interface.
The second experiment is about handling file paths. I try a different representations of paths based on the idea that parsing a path string should be done only once and that it’s easier to manipulate an array of indexes to a string than the string itself.
The representation is a string and array of delimiters in that string. Each element of the array provides index of the first and last letter of the path:
We can keep path delimiters in the string:
“/home/test/src/file.txt”
((2, 5), (7, 10), (12, 14), (16, 23))
With this representation, getting basename or subdirectories is really fast and easy. All this could be encapsulated to get so that users cannot mess with the internal representation.
There’s the question of memory allocation, which I’m not sure how to handle.
Food for thought...