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

Consistent notation for VAddr/PAddr #101

Closed
hawkw opened this issue May 27, 2017 · 1 comment
Closed

Consistent notation for VAddr/PAddr #101

hawkw opened this issue May 27, 2017 · 1 comment
Labels
contrib/easy Contributing: this issue likely requires less time or experience than other issues. contrib/help wanted Contributing: help is requested or needed by the filer of this issue. kind/feature Kind: this issue is a feature.

Comments

@hawkw
Copy link
Member

hawkw commented May 27, 2017

Currently, we tend to format both virtual (VAddr) and physical (PAddr) addresses using the "{:#p}" format specifier for pointers. This works fine, but makes telling whether an address is physical or virtual difficult when reading through logs, et cetera.

It'd be nice if we could have a consistent notation for these. I suggest possibly replacing "0xff00" with "Pxff00 for physical addresses and Vxff00 for virtual addresses, or appending a P/V to the end of the hex address, like 0xff00_p.

@hawkw hawkw added contrib/easy Contributing: this issue likely requires less time or experience than other issues. kind/feature Kind: this issue is a feature. contrib/help wanted Contributing: help is requested or needed by the filer of this issue. labels May 27, 2017
@hawkw
Copy link
Member Author

hawkw commented May 27, 2017

Someone who knows how string formatting works in Rust could probably implement this fairly easily without any OS dev knowledge.

Therefore, I'm tagging it as "easy" and "help wanted", in case anybody's looking for a good issue for a first-time contributor...

@hawkw hawkw closed this as completed in adebcff Jun 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contrib/easy Contributing: this issue likely requires less time or experience than other issues. contrib/help wanted Contributing: help is requested or needed by the filer of this issue. kind/feature Kind: this issue is a feature.
Projects
None yet
Development

No branches or pull requests

1 participant