kmc-solid: Use the filesystem thread-safety wrapper

[kawadakk]

Fixes the thread unsafety of the std::fs implementation used by the *-kmc-solid_* Tier 3 targets.

Neither the SOLID filesystem API nor built-in filesystem drivers guarantee thread safety by default. Although this may suffice in general embedded-system use cases, and in fact the API can be used from multiple threads without any problems in many cases, this has been a source of unsoundness in std::sys::solid::fs.

This commit updates the implementation to leverage the filesystem thread-safety wrapper (which uses a pluggable synchronization mechanism) to enforce thread safety. This is done by prefixing all paths passed to the filesystem API with \TS. (Note that relative paths aren't supported in this platform.)

[rust-highfive]

r? @yaahc

(rust-highfive has picked a reviewer for you, use r? to override)

[yaahc]

This commit updates the implementation to leverage the filesystem thread-safety wrapper (which uses a pluggable synchronization mechanism) to enforce thread safety. This is done by prefixing all paths passed to the filesystem API with \TS. (Note that relative paths aren't supported in this platform.)

For my own edification, could you point me towards the API docs that outline how the \TS threadsafety prefix works on SOLID? I'm unfamiliar with the SOLID platform and having trouble finding the API docs.

[kawadakk]

For my own edification, could you point me towards the API docs that outline how the \TS threadsafety prefix works on SOLID? I'm unfamiliar with the SOLID platform and having trouble finding the API docs.

I'm afraid this part is one of the areas where the documentation is lagging behind.

To give a brief explanation, the thread-safety wrapper is an optional mechanism of SOLID Core Services Filesystem that adds thread safety to otherwise-unsafe filesystem drivers. The basic idea is that all accesses made through this prefix are somehow made safe (at a runtime cost and complication with RTOS interaction), as long as other parts of the application don't do the otherwise.

Since std is dependent on an operating system anyway, I think it's a fair assumption that all prospective SOLID applications including Rust code don't have much issue taking the trade-off regarding the use of the wrapper and using it exclusively.

[yaahc]

Sounds good, thank you for the explanation ^_^

@bors r+

[bors]

📌 Commit 64406c5 has been approved by yaahc