VSH: Filesystem Mounting Enhancement

[brian218]

Made the VSH willing to access /dev_usbXXX, which wasn't deemed mounted by VSH when the device wasn't in the list provided by sys_fs_get_mount_info().

For example, PS3UPDAT.PUP in /dev_usb000/PS3/UPDATE/ now can be detected by the VSH with this PR.

[Darkhost1999]

I noticed a few things
dev_usb000/MUSIC
dev_usb000/PICTURE
dev_usb000/PS3/THEME
dev_usb000/VIDEO
While working on my PS3 doesn't work here. The usb doesn't even show up on xmb as connected.

The only path detected was dev_usb000/PS3/UPDATE and it appropriately returned the error that the pup version couldn't be read.

And while you're doing this PR. What about these other USBs? Why leave these out
dev_usb // (SYS_DEV_USB)
dev_usb000 // (CELL_FS_IOS:USB_MASS_STORAGE000)
dev_usb001 // (CELL_FS_IOS:USB_MASS_STORAGE001)
dev_usb002 // (CELL_FS_IOS:USB_MASS_STORAGE002)
dev_usb003 // (CELL_FS_IOS:USB_MASS_STORAGE003)
dev_usb004 // (CELL_FS_IOS:USB_MASS_STORAGE004)
dev_usb005 // (CELL_FS_IOS:USB_MASS_STORAGE005)

At the least usb mass storage 1-5 should be the same as 0 right? Can we add those because that's how it should be? Have we found out anything about sys_dev_usb?

[brian218]

I noticed a few things dev_usb000/MUSIC dev_usb000/PICTURE dev_usb000/PS3/THEME dev_usb000/VIDEO While working on my PS3 doesn't work here. The usb doesn't even show up on xmb as connected.

The only path detected was dev_usb000/PS3/UPDATE and it appropriately returned the error that the pup version couldn't be read.

And while you're doing this PR. What about these other USBs? Why leave these out dev_usb // (SYS_DEV_USB) dev_usb000 // (CELL_FS_IOS:USB_MASS_STORAGE000) dev_usb001 // (CELL_FS_IOS:USB_MASS_STORAGE001) dev_usb002 // (CELL_FS_IOS:USB_MASS_STORAGE002) dev_usb003 // (CELL_FS_IOS:USB_MASS_STORAGE003) dev_usb004 // (CELL_FS_IOS:USB_MASS_STORAGE004) dev_usb005 // (CELL_FS_IOS:USB_MASS_STORAGE005)

At the least usb mass storage 1-5 should be the same as 0 right? Can we add those because that's how it should be? Have we found out anything about sys_dev_usb?

I can add the other dev_usb to the mount_info list of course, though I think we should eventually implement dynamic mount_info list reflecting what is actually mounted or unmounted by vfs::mount or vfs::unmount() in real time.

[brian218]

@Darkhost1999 I've added the temporary workaround for /dev_usb000 to /dev_usb005.

[brian218]

Managed to further implement sys_fs_get_mount_info() stuff so that it can reflect the actually mounted devices in real time.

[Darkhost1999]

Your example for dev_usb/PS3/UPDATE is still valid

But dev_usb000/MUSIC
dev_usb000/PICTURE
dev_usb000/PS3/THEME
dev_usb000/VIDEO
aren't detected.
Here is for themes

Here is for Music/xmb

Why doesn't it show like

Is that achievable here or a future PR?

[Darkhost1999]

There is a theme inside dev_flash/vsh/resource/theme you can use inside the dev_usb000/PS3/Theme path for testing if you don't have a .p3t

[brian218]

Up to 8 USBs (from dev_usb000 to dev_usb007) are supported now.

[brian218]

Your example for dev_usb/PS3/UPDATE is still valid But dev_usb000/MUSIC dev_usb000/PICTURE dev_usb000/PS3/THEME dev_usb000/VIDEO aren't detected. Here is for themes Here is for Music/xmb Why doesn't it show like Is that achievable here or a future PR?

Interesting. We can look into these in another PR in the future.
I think currently this PR can be reviewed and merged since it does fix something that didn't work at all (such as firmware check from USB).

[brian218]

After this PR, the arcade XMB can be fully accessible and operable.

[brian218]

"Install Package Files" from USB also works smoothly.

[Darkhost1999]

I thought that was confirmed working before this PR. Several months ago

[brian218]

I thought that was confirmed working before this PR. Several months ago

I don't think so. You'll probably get error 80029567 and 80029564.

[elad335]

I think it's safer to not use a member to tell if mounted, just vfs::get or some other indirect way to extract data from vfs. It's because it has issues when relainching emulation.

[elad335]

or actually reset is_mounted on FXO destruction using a custom destructor in a struct, similar to how raw_spu_cleanup struct behaves.

[brian218]

I think it's safer to not use a member to tell if mounted, just vfs::get or some other indirect way to extract data from vfs. It's because it has issues when relainching emulation.

I get you.
I need some time to come up with an implementation to fix it up.

[brian218]

or actually reset is_mounted on FXO destruction using a custom destructor in a struct, similar to how raw_spu_cleanup struct behaves.

Fixed.

[brian218]

Wait, I have some ideas.

[brian218]

I think it's safer to not use a member to tell if mounted, just vfs::get or some other indirect way to extract data from vfs. It's because it has issues when relainching emulation.

Okay, it no longer relies on u8 is_mounted member to determine the mount status.

[brian218]

What else is still keeping this PR from being merged?

[elad335]

mount_point_reset needs to be ordered after vfs_manager, maybe use SAVESTATE_INIT_POS fir it.

[brian218]

mount_point_reset needs to be ordered after vfs_manager, maybe use SAVESTATE_INIT_POS fir it.

You mean I should move mount_point_reset to VFS.cpp?

[elad335]

No I mean you need to ensure the destructor is called before vfs_manager destructor.

[brian218]

No I mean you need to ensure the destructor is called before vfs_manager destructor.

How about doing mount_point_reset's work (unmount all mount point) in vfs_manager destructor?

[elad335]

You just need to add 2 lines, in vfs_manager and moint_point_resend. See other usages if this macro for example.

[brian218]

You just need to add 2 lines, in vfs_manager and moint_point_resend. See other usages if this macro for example.

Could you please advise what value of x I should use for SAVESTATE_INIT_POS(x)?

[brian218]

I didn't see any new problem in the log with current implementation.
mount_point_reset always works as expected.

[elad335]

It's because the bug depends on which gets compiled first, sys_fs.cpp or VFS.cpp.

[elad335]

You can search values used on other SAVESTATE_INIT_POS and come up with new ones, mount_point_reset value must be higher than vfs_manager struct

[brian218]

You can search values used on other SAVESTATE_INIT_POS and come up with new ones, mount_point_reset value must be higher than vfs_manager struct

@elad335 How does it look now?