File Management: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
 
(One intermediate revision by one other user not shown)
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 at [[VFS_Implementation|VFS Implementation]]
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:
 
 
Also [[SceExfatfs]] also has two cahe. It is as follows.


cache_all_fat_data
cache_all_fat_data
Line 27: Line 27:
   pd0:
   pd0:


But it's unclear how these caches work.
However it is unclear how these caches work.


== API ==
== API ==
Finally, we have [[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.


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.


{| class="wikitable"
|-
! Name !! Dependence !! Description
|-
| ncache || - || name cache per vnode. SceIofilemgr uses this to search for entries in file system. If it is not found in ncache, execute sceVopLookup on the target mnt. If the entry is still not found, it will be an api error.
|-
| vfs || ncache || base vfs. like exfat/tty/host/md.
|-
| mnt || vfs || moint point. like ux0: / sdstor0: / tty0:.
|-
| vnode || mnt || The vnode per entry.
|-
| VfsFile (fd) || vnode || -
|}


[[Category:System]]
[[Category:System]]

Latest revision as of 06:33, 15 November 2023

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.

Name Dependence Description
ncache - name cache per vnode. SceIofilemgr uses this to search for entries in file system. If it is not found in ncache, execute sceVopLookup on the target mnt. If the entry is still not found, it will be an api error.
vfs ncache base vfs. like exfat/tty/host/md.
mnt vfs moint point. like ux0: / sdstor0: / tty0:.
vnode mnt The vnode per entry.
VfsFile (fd) vnode -