obhq / obliteration

Experimental PS4 emulator written in Rust for Windows, macOS and Linux
https://obliteration.net
MIT License
601 stars 17 forks source link

Implements tmpfs root, mkdir and lookup #733

Closed SuchAFuriousDeath closed 4 months ago

SuchAFuriousDeath commented 4 months ago

@ultimaweapon I would've done more here, but I don't know how to get TempFs from Arc\<dyn Filesystem>.

ultimaweapon commented 4 months ago

@ultimaweapon I would've done more here, but I don't know how to get TempFs from Arc.

Where do you need this?

SuchAFuriousDeath commented 4 months ago

@ultimaweapon I would've done more here, but I don't know how to get TempFs from Arc.

Where do you need this?

In mkdir, I need access to Nodes.

ultimaweapon commented 4 months ago

@ultimaweapon I would've done more here, but I don't know how to get TempFs from Arc.

Where do you need this?

In mkdir, I need access to Nodes.

You can store TempFs in the VnodeBackend. Take a look on VnodeBackend on HostFS for an example.

SuchAFuriousDeath commented 4 months ago

By the way, I figured out the rough outline of mkdir and lookup, it seems to work.

SuchAFuriousDeath commented 4 months ago

Also, I don't think we can look up /app/eboot.bin, because we don't have a thread, so the file will be looked up from the root of the filesystem instead of the root of the process

SuchAFuriousDeath commented 4 months ago

I included a rough implementation of VnodeBackend - it's almost correct, I just need inserting into nullhash, but the funny thing is that the Vnode probably should have a Arc\<dyn VnodeBackend> after all (instead of a box), otherwise there's no way to store the backend in the null hashtable.

SuchAFuriousDeath commented 4 months ago

@ultimaweapon By the way, I would like you to focus on the filesystem this weekend if you have time. I have 9 days of vacation ahead of me, so maybe we could finally break out of the filesystem prison

ultimaweapon commented 4 months ago

@ultimaweapon By the way, I would like you to focus on the filesystem this weekend if you have time. I have 9 days of vacation ahead of me, so maybe we could finally break out of the filesystem prison

That why we have another people to review the code so it does not blocked by me.

SuchAFuriousDeath commented 4 months ago

Well, yes, this PR should probably still be reviewed by you.

SuchAFuriousDeath commented 4 months ago

I myself can't even tell if this PR makes sense :sweat_smile:

ultimaweapon commented 4 months ago

Also, I don't think we can look up /app/eboot.bin, because we don't have a thread, so the file will be looked up from the root of the filesystem instead of the root of the process

Seems like it time to move rtld to the correct place so it have access to the process that own it.

Not sure if you saw this one: https://github.com/obhq/obliteration/pull/733#discussion_r1518817279

SuchAFuriousDeath commented 4 months ago

image

ultimaweapon commented 4 months ago

I can't see your comment because it is pending.

SuchAFuriousDeath commented 4 months ago

Looking up eboot.bin now fails in tmpfs :eyes: . It's actually really hard to debug this, because the whole lookup relies on several things being correct at once and it's difficult to tell which one is wrong.

ultimaweapon commented 4 months ago

Looking up eboot.bin now fails in tmpfs :eyes: . It's actually really hard to debug this, because the whole lookup relies on several things being correct at once and it's difficult to tell which one is wrong.

You can step in a debugger to find out which line is wrong.

SuchAFuriousDeath commented 4 months ago

Whoa, I didn't expect you to be awake :flushed: . I've drawn a sketch of the whole filesystem and I think I have it. It might have something to do with the fact that we don't look up the target vnode in nullfs :joy:

SuchAFuriousDeath commented 4 months ago

image

SuchAFuriousDeath commented 4 months ago

How do I lookup a vnode in the mount function? :thinking: . I suppose mount functions should take a reference to the filesystem as an extra argument? :thinking:

SuchAFuriousDeath commented 4 months ago

image

Anyway, besides this silly little thing the specific way the lookup failed seems to suggest that everything else is correct.

SuchAFuriousDeath commented 4 months ago

There's something fishy going on here. When nullfs is being mounted with target = "/mnt/sandbox/pfsmnt/CUSA07010-app0", the looked up vnode belongs to tmpfs, when it should belongs to exfatfs (Or pfs, which we are faking with exfatfs).

SuchAFuriousDeath commented 4 months ago

There's something fishy going on here. When nullfs is being mounted with target = "/mnt/sandbox/pfsmnt/CUSA07010-app0", the looked up vnode belongs to tmpfs, when it should belongs to exfatfs (Or pfs, which we are faking with exfatfs).

Or... should it? I'm not so sure anymore. Obviously, looking up eboot.bin has to pass through hostfs... But how does that happen from a tmpfs vnode?

SuchAFuriousDeath commented 4 months ago

Oops, I was looking up the path in wrong variable... everything is actually fine :sweat:

SuchAFuriousDeath commented 4 months ago

@ultimaweapon Just so you know, I did this: image So that the links are clickable in VS code in the command line

SuchAFuriousDeath commented 4 months ago

Also, the way I generate hashes for the mount and the vnode is different from FreeBSD... but I don't really care too much, it's sufficient for now.

ultimaweapon commented 4 months ago

Why not wait for a proper review from a developer? Especially a big PR like this. The reason we required a review is because we want one more eye to see if everything look okay. If we keep going like this it is useless to have a review system.

ultimaweapon commented 4 months ago

@VocalFan should be a reviewer only for non-code changes or a small PR and a last resort on a big PR only when we don't have other developers around.

The rule of thumb is if you don't understand what the code does, do not approve it.

SuchAFuriousDeath commented 4 months ago

You're right, sorry. We got too excited. Hopefully there aren't too many things wrong.