HAL.Filesystem: memory allocations about ada_drivers_library HOT 4 CLOSED

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".)

from ada_drivers_library.

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!

from ada_drivers_library.

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 [email protected] 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.

from ada_drivers_library.

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.

from ada_drivers_library.