FS subfiles are created with File::OpenSubFile, they have a start offset that must be added to all read/write operations.
The implementation in this commit is done using a new FileBackend that wraps the FS::File along with the start offset.
Instead of using an unsigned int as a parameter and expecting a user to
always pass in the correct values, we can just convert the enum into an
enum class and use that type as the parameter type instead, which makes
the interface more type safe.
We also get rid of the bookkeeping "NUM_" element in the enum by just
using an unordered map. This function is generally low-frequency in
terms of calls (and I'd hope so, considering otherwise would mean we're
slamming the disk with IO all the time) so I'd consider this acceptable
in this case.
There were a few places where nested namespace specifiers weren't being
used where they could be within the service code. This amends that to
make the namespacing a tiny bit more compact.
Previously, these were sitting outside of the Kernel namespace, which
doesn't really make sense, given they're related to the Thread class
which is within the Kernel namespace.
Some services can have multiple clients at the same time, and they identify the different clients using the server session as a key.
This parameter (if present) should be a structure that contains the per-session data for each service.
The data can be retrieved using ServiceFramework::GetSessionData(session)
The File class now holds a list of connected sessions along with data unique to each session.
A subfile is a window into an existing file. They have a few limitations compared to normal files:
* They can't be written to.
* They can't be flushed.
* Their size can not be changed.
* New subfiles can't be created from another subfile.
We don't yet implement the SEEDDB store.
This number is supposed to be modified by the AddSeed function (0x087A0180) but there's too little info about it on 3dbrew.
The real kernel requires services to set up their static buffer targets ahead of time. This implementation does not require that and will simply create the storage for the buffers as they are processed in the incoming IPC request.
Static buffers are kept in an unordered_map keyed by their buffer id, and are written into the already-setup area of the request thread when responding an IPC request.
This fixes a regression (crash) introduced in #2992.
This PR introduces more warnings due to the [[deprecated]] attribute being added to void PushStaticBuffer(VAddr buffer_vaddr, size_t size, u8 buffer_id); and VAddr PopStaticBuffer(size_t* data_size);
The loaders now register each loaded ROM with the SelfNCCH factory, which keeps the data around for the duration of the emulation session.
When opening the SelfNCCH archive, the factory queries the current program's programid and uses that as a key to the map that contains the NCCHData structure (RomFS, Icon, Banner, etc).
3dsx files do not have a programid and will use a default of 0 for this value, thus, only 1 3dsx file with RomFS is loadable at the same time.
