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 (https://github.com/AdaCore/Ada_Drivers_Library/issues/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:
A single point to handle current working directory and relative paths
A single point to parse the paths (see below)
Mount filesystems
keep a reference to which file system allocated the handle and directly call it when closing a handle
Close handles associated with a filesystem when unmounting it
Maybe handle permissions
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:
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.
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 (https://github.com/AdaCore/Ada_Drivers_Library/issues/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...