This syscall can be used by clients to modify the selection, the
relative priority and the accompanying parameter structs for the
backends the client wants to use. As it doesn't fit any specific
category of existing Client trait, add it into the basic
PollClient - basically it's a meta-syscall, so this is the best fit.
The syscalls ReadDirFirst, ReadDirNext, ReadDirFilesFirst, ReadDirFilesNext
implement Trussed-based filesystem traversal. The "cursor" is however kept
in two quasi-global variables, so concurrent walks interfere with each other.
Move these two cursor variables into the new ClientId struct instead.
The 'service' module uses ClientContext (via pipe::ServiceEndpoint::client_ctx) to
carry client-specific metadata. Previously, this was only the ID string, so
a type alias for PathBuf was sufficient. With the upcoming dynamic syscall
dispatch, the amount of client-specific state Trussed has to keep is going
to grow significantly. This commit creates the necessary scaffolding.
Minor changes:
- in the filesystem-based software store implementations, use an explicit
PathBuf - drop the ClientContext type import / alias redeclaration
- pass ClientId around as a mutable reference in the reply_to() machinery,
as we do not want to clone this structure arbitrarily when it gets large
(as a sentinel, also stop deriving Clone for it)
* Generic `<P: Platform>` is never needed within `*KeyStore`
* KeyStore only needs `P::S` which is `Store`
* Now consistent with the other `*Store`s (which only use <S>)
With this patch, we separate the store management (i. e. resetting it
when a Service is constructed) from the actual Store implementation.
This allows us to have a static lifetime for our clients as we can take
ownership of all required resources.
This is similar to try_as_new_client except that the resulting
ClientImplementation owns the service instead of a mutable reference to
it, making it 'static
Existing constructors (allocate(), mount(), attach_else_format()) all do
the heavy lifting of the construction. Users might want to do those steps
on their own to have more fine-grained control over which areas of storage
are safe to reformat and generally better error handling. Therefore add a
low-level constructor that only creates the Fs wrappers and populates the
ifs/efs/vfs globals.
The number of supported clients is configurable through a crate feature,
but the feature is only honored in the Interchange handling in src/pipe.rs.
The config::MAX_SERVICE_CLIENTS type, which is used to set the size of the
"endpoints" Vec<> in src/service.rs, was still hardcoded to consts::U5.