Rename XCr0 and CR4 flags

[josephlr]

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?

[ethindp]

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

[josephlr]

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 next, and merge it.

[phil-opp]

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.

[josephlr]

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.

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 master branch, as this can now be part of a "normal" release.

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.

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.