-
Notifications
You must be signed in to change notification settings - Fork 132
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
Rename XCr0 and CR4 flags #275
Conversation
I think that's everything. I'll check sometime soon when i have time
to make sure that they aren't backwards.
…On 7/16/21, Joseph Richey ***@***.***> wrote:
Breaking changes from #272, part of #262
@ethindp does this include all the breaking changes from your previous PR?
You can view, comment on, or merge this pull request online at:
#275
-- Commit Summary --
* XCr0: rename YMM to AVX
* Cr4: Rename PROTECTION_KEY to PROTECTION_KEY_USER
-- File Changes --
M src/registers/control.rs (2)
M src/registers/xcontrol.rs (14)
-- Patch Links --
https://github.com/rust-osdev/x86_64/pull/275.patch
https://github.com/rust-osdev/x86_64/pull/275.diff
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#275
--
Signed,
Ethin D. Probst
|
The changes here seem good. We will want to wait until #280 is merged, then we will change the branch of this PR back to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks!
I wonder if bitflags
allows to annotate individuals flags with #[deprecated]
? Then we could deprecate the old flags first as part of a normal release and then remove them in the breaking release? This way, we could let the compiler tell the users how they should adjust their code.
I'm not sure if a deprecation period is worth it though, as this only affects two flags that are probably only used by a small number of people currently.
Deprecate YMM Signed-off-by: Joe Richey <[email protected]>
Deprecate PROTECTION_KEY Signed-off-by: Joe Richey <[email protected]>
This is a good idea! I changed the PR to keep the old constants, but mark them as deprecated. The rest of the PR is the same (all internal usage is changed to use the new names). I also changed the base to be the
I think having a deprecation in 0.14.5 and removal in 0.15 is fine. The change isn't too hard, and it would make it easier for the small number of users to upgrade. It's a short window as-is. |
4abf353
to
b8acbda
Compare
Breaking changes from #272, part of #262
NOTE: this was changed to only deprecate the new constant names, so it is no longer a breaking change.
@ethindp does this include all the breaking changes from your previous PR?