Closed SuchAFuriousDeath closed 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?
@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 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.
By the way, I figured out the rough outline of mkdir and lookup, it seems to work.
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
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.
@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 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.
Well, yes, this PR should probably still be reviewed by you.
I myself can't even tell if this PR makes sense :sweat_smile:
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
I can't see your comment because it is pending.
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.
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.
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:
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:
Anyway, besides this silly little thing the specific way the lookup failed seems to suggest that everything else is correct.
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).
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?
Oops, I was looking up the path in wrong variable... everything is actually fine :sweat:
@ultimaweapon Just so you know, I did this: So that the links are clickable in VS code in the command line
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.
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.
@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.
You're right, sorry. We got too excited. Hopefully there aren't too many things wrong.
@ultimaweapon I would've done more here, but I don't know how to get TempFs from Arc\<dyn Filesystem>.