HAL.Filesystem: memory allocations

[pmderodat]

Hi,

In HAL.Filesystem, the FS_Driver.Open primitive creates a File_Handle_Ref, so I guess users are supposed to deallocate the handle when done with it (after calling Close, which have no access view). If this is indeed how file handles are supposed to be handled, what about providing in HAL.Filesystem a procedure to deallocate one? This would avoid for all users the pain of instantiating one. :-) Likewise for directory handles.

[Fabien-Chouteau]

Hi @pmderodat ,

I'm not very happy about that part of the interface :) It's not clear (and not documented...) but the client doesn't have to do allocation and de-allocation of the handles, it's the responsibility of the FS_Driver. If you have a look at ARM/cortex_m/src/semohosting-filesystem.adb, the close function doesn't de-allocate the handle but mark it as "not open", which means that the client should stop using the handle after calling Close() because it is invalid. I recon this is not great...

In my first version, Close() was a primitive of FS_Driver not File_Handle, and the specification was something like:

procedure Close (This : in out FS_Driver; Handle : in out File_Handle_Ref) with Post => Handle = null;

This is way more clear and clean. The problem is that I want to be able to have a hierarchy of file systems:

• VFS "/"
  • VFS "mnt/"
    • FAT "sdcard/"
    • FAT "usb_drive/"
  • Semihosting "host/"
  • NTFS "remote/"

Users would always talk to the root VFS so a call to Open() can return a File_Handle_Ref from any FS implementation (VFS, FAT, Semihosting, NTFS). The problem is, when the client is calling Close() on the root VFS, how do we know which FS_Driver instance is the owner of the handle? How do we know who has to handle the de-allocation.

(Note that allocation and de-allocation here don't necessarily mean "new" and Ada.Unchecked_Deallocation. FS_Drivers can have internal pools of handles and manage them "manually".)

[pmderodat]

Ok, so handles (I guess this applies both to files and directory handles) are owned by the FS that created them so these take care of actual memory allocations. I’ll try to write this down in HAL.Filesystem’s spec. I think getting this right will solve my problems. ;-)

Thanks!

[lambourg]

Note that ideally, we should never allocate stuff here, but instead use handles from a static pool of handles.

Le 16 oct. 2016 à 10:24, Pierre-Marie de Rodat notifications@github.com a écrit :

Ok, so handles (I guess this applies both to files and directory handles) are owned by the FS that created them so these take care of actual memory allocations. I’ll try to write this down in HAL.Filesystem’s spec. I think getting this right will solve my problems. ;-)

Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Fabien-Chouteau]

As I said I my first reply, allocation and de-allocation can take different shape or form.

Pools are interesting because you statically know the amount of memory used, but on the other hand you have to mange the resources "by hand" (implementing your own allocation). Depending on the application it can also be a waste of memory, for instance if the application uses a lot of file handles at initialization to load configuration files or assets. The memory allocated for the pools will remain unused most of the time.

In the end it's an FS_Driver implementation choice, but I think that both pools and heap allocation should be available for the users.