The immutable API for embedded-sdmmc is problematic, because the File objects hold a reference to their parent filesystem - which is in a big context structure. You then can't, say, write to the UART while holding an open File (which is nonsense).
Moving the disk controller to its own global structure with its own lock helps, but you can still only hold files while you have the lock open. You couldn't, for example, store an open file, release the disk lock and then come back to the file later on.
I propose instead, that Monotron creates its own Handle type which close themselves on Drop. They would implement the basic read/write/seek/close operations, and any access on a file Handle would temporarily grab the lock for the disk, or any access on a uart Handle would temporarily grab the lock for the UART.
This can be implemented with the standard mutable embedded-sdmmc API.
thejpster
commented
5 years ago
The immutable API for
embedded-sdmmcis problematic, because theFileobjects hold a reference to their parent filesystem - which is in a big context structure. You then can't, say, write to the UART while holding an open File (which is nonsense).Moving the disk controller to its own global structure with its own lock helps, but you can still only hold files while you have the lock open. You couldn't, for example, store an open file, release the disk lock and then come back to the file later on.
I propose instead, that Monotron creates its own Handle type which close themselves on
Drop. They would implement the basic read/write/seek/close operations, and any access on a file Handle would temporarily grab the lock for the disk, or any access on a uart Handle would temporarily grab the lock for the UART.This can be implemented with the standard mutable embedded-sdmmc API.