File Management: Difference between revisions
CelesteBlue (talk | contribs) No edit summary |
|||
| Line 1: | Line 1: | ||
The Vita has a multi-layered file management system that is similar (and may be based off of) the [https://web.archive.org/web/20161026190602/http://www.solarisinternals.com/si/reading/vnode.pdf BSD vnode] structure. Different kernel modules handle each layer. All information can be found | The PS Vita has a multi-layered file management system that is similar (and may be based off of) the [https://web.archive.org/web/20161026190602/http://www.solarisinternals.com/si/reading/vnode.pdf BSD vnode] structure. Different kernel modules handle each layer. All information can be found at [[VFS_Implementation|VFS Implementation]]. | ||
== Hardware == | == Hardware == | ||
At the lowest level, we have the device drivers for the various virtual and real devices on the system. For example [[SceSdif]] interacts with the SDIO interface for speaking to the [[eMMC]] and any other SD interfaces. | At the lowest level, we have the device drivers for the various virtual and real devices on the system. For example [[SceSdif]] interacts with the SDIO interface for speaking to the [[eMMC]] and any other SD interfaces. | ||
== Block == | == Block == | ||
Next is the block level. This is device blocks, not file system blocks (which is at a higher level). [[SceSdstor]] manages the blocks and also exports block level devices to system applications. Block level encryption and decryption also takes place at this level. All user-facing devices including [[eMMC]], [[Memory Card]], and [[Game Card]] are encrypted at the block level. Partitions are also managed at this level. One device can export multiple partitions. [[Partitions]] tables are a proprietary format. | Next is the block level. This is device blocks, not file system blocks (which is at a higher level). [[SceSdstor]] manages the blocks and also exports block level devices to system applications. Block level encryption and decryption also takes place at this level. All user-facing devices including [[eMMC]], [[Memory Card]], and [[Game Card]] are encrypted at the block level. Partitions are also managed at this level. One device can export multiple partitions. [[Partitions]] tables are a proprietary format. | ||
== File System == | == File System == | ||
The file system is implemented on top of the block drivers. [[SceExfatfs]] is used to recognize FAT16, FAT32, and exFAT partitions. | The file system is implemented on top of the block drivers. [[SceExfatfs]] is used to recognize FAT16, FAT32, and exFAT partitions. | ||
== Caching == | == Caching == | ||
Next is a layer of caching implemented by [[SceFios2Kernel]]. | Next is a layer of caching implemented by [[SceFios2Kernel]]. [[SceExfatfs]] also has two caches as follows: | ||
cache_all_fat_data | cache_all_fat_data | ||
| Line 27: | Line 27: | ||
pd0: | pd0: | ||
However it is unclear how these caches work. | |||
== API == | == API == | ||
Finally, there is [[SceIofilemgr]] which exposes IO APIs such as <code>sceIoOpen</code> for applications to use to access files. Different application may deal with different encrypted format files. | |||
Implementation: Mainly vfs only. Lookup the `File System` to create a new vfs node and connect it to the vfs link. This works like a kind of cache. | Implementation: Mainly vfs only. Lookup the `File System` to create a new vfs node and connect it to the vfs link. This works like a kind of cache. | ||
| Line 39: | Line 38: | ||
If the final vfs node is found, create a uid object and return uid as fd to the user. | If the final vfs node is found, create a uid object and return uid as fd to the user. | ||
For sceIoRead, get the object from uid and convert it to vfs node. Then call sceVopRead with that vfs node as an argument. sceVopRead calls "File System"'s vop_read. | For sceIoRead, get the object from uid and convert it to vfs node. Then call sceVopRead with that vfs node as an argument. sceVopRead calls "File System"'s vop_read. | ||
Revision as of 19:39, 6 September 2022
The PS Vita has a multi-layered file management system that is similar (and may be based off of) the BSD vnode structure. Different kernel modules handle each layer. All information can be found at VFS Implementation.
Hardware
At the lowest level, we have the device drivers for the various virtual and real devices on the system. For example SceSdif interacts with the SDIO interface for speaking to the eMMC and any other SD interfaces.
Block
Next is the block level. This is device blocks, not file system blocks (which is at a higher level). SceSdstor manages the blocks and also exports block level devices to system applications. Block level encryption and decryption also takes place at this level. All user-facing devices including eMMC, Memory Card, and Game Card are encrypted at the block level. Partitions are also managed at this level. One device can export multiple partitions. Partitions tables are a proprietary format.
File System
The file system is implemented on top of the block drivers. SceExfatfs is used to recognize FAT16, FAT32, and exFAT partitions.
Caching
Next is a layer of caching implemented by SceFios2Kernel. SceExfatfs also has two caches as follows:
cache_all_fat_data
sa0:
cluster_cache
sd0: os0: tm0: sa0: pd0:
However it is unclear how these caches work.
API
Finally, there is SceIofilemgr which exposes IO APIs such as sceIoOpen for applications to use to access files. Different application may deal with different encrypted format files.
Implementation: Mainly vfs only. Lookup the `File System` to create a new vfs node and connect it to the vfs link. This works like a kind of cache.
For example, sceIoOpen first looks for a vfs link from path. If any vfs node is not found in the middle, use "File System"'s lookup to create a new vfs node and continue the search.
If the final vfs node is found, create a uid object and return uid as fd to the user.
For sceIoRead, get the object from uid and convert it to vfs node. Then call sceVopRead with that vfs node as an argument. sceVopRead calls "File System"'s vop_read.