Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

std::path handling for different resource schemes #13

Open
ian-h-chamberlain opened this issue Feb 13, 2022 · 7 comments
Open

std::path handling for different resource schemes #13

ian-h-chamberlain opened this issue Feb 13, 2022 · 7 comments

Comments

@ian-h-chamberlain
Copy link

ian-h-chamberlain commented Feb 13, 2022

Broke this out of #11 since I think it's a separate issue from reading the files themselves, but we need to figure out some way to handle the weirdness of using paths like smdc:/, romfs:/.


Edit: I think we might also need to reconsider the path scheme (or add OS-specific helpers), since I have noticed some weird behavior with .parent() and .pop().... and the romfs:/ seems a bit nonstandard for unix-like OSes.

Edit: seems like RedoxOS already uses a similar scheme (and has some support in sys::path), so maybe we can piggyback off of that: https://doc.redox-os.org/book/ch04-06-schemes.html

Originally posted by @ian-h-chamberlain in #11 (comment)

@ian-h-chamberlain
Copy link
Author

It seems this is still unsolved for redox itself:

@Meziu
Copy link
Owner

Meziu commented Feb 13, 2022

Those Redox issues are quite old, has nothing of those made it into std? I wonder what the Redox users are doing to prevent that...

@AzureMarker
Copy link

It sounds like they are still using a fork. Looking that the open issue, I think we could try making a PR of our own against std for either option 4 or 5.

@ian-h-chamberlain
Copy link
Author

ian-h-chamberlain commented Feb 15, 2022

I found some of the changes used in Redox: https://gitlab.redox-os.org/redox-os/rust/-/commit/6ab9e2656b8aa3d43c4977cc09a098dec7bcdafd and https://gitlab.redox-os.org/redox-os/rust/-/commit/f5eee2c14346c7c6e919721e4b0221f73f2fca9e

Seems like they never ended up upstreaming those changes since the Rust maintainers didn't really want to expand those APIs in std::path... It seems like option 5 is the most likely to be accepted upstream, and clearly it's not a huge priority for the Redox folks to get that kind of support upstream.

Maybe we can implement an OS extension trait for now, and just try to make a non-breaking change like rust-lang#51537 to at least fix components() in the meantime?

Edit: one more reference, which actually includes a reference to the 3DS (!): rust-lang-nursery/portability-wg#18

@jackpot51
Copy link

@ian-h-chamberlain I still need help determining the best option and then I would implement it.

@ian-h-chamberlain
Copy link
Author

@jackpot51 I've asked for some help on Zulip, maybe we can get some additional feedback there. My thinking is that the "Option 5" there seems like the right way to go, but it probably requires some buy-in from the libs team before being implemented.

@FenrirWolf
Copy link

I like how I ran into this shit 3 years ago and it's still not fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants