search

gz / rust-cpuid

cpuid library in rust.
https://docs.rs/raw-cpuid/
MIT License
153 stars 45 forks source link

[WIP] Micro architecture parsing #177

Open GuillaumeDIDIER opened 4 months ago

GuillaumeDIDIER commented 4 months ago

Implement micro-architecture parsing, as proposed in #176

This design attempts to capture the subtleties of Skylake and Alder Lake (Hybrid SoCs, and many different SoCs variation using the same core design).

GuillaumeDIDIER commented 4 months ago

Before I implement the whole parsing, I wouldn't mind a review of the design.

I am also considering changing Heterogeneous to Hybrid, and Homogenous to something simpler to spell, if you have any idea.

@gz for a first review.

GuillaumeDIDIER commented 4 months ago

Note, because adding more vendor in the future seems possible, I've marked the Vendor enum as non_exhaustive, and all the micro-architecture ones will also be non_exhaustive.

This is a breaking change for users, a major version will be needed, but then adding new vendors or micro-architectures will not require breaking changes as they would otherwise have.

mert-kurttutan commented 4 months ago

Note, because adding more vendor in the future seems possible, I've marked the Vendor enum as non_exhaustive, and all the micro-architecture ones will also be non_exhaustive.

This is a breaking change for users, a major version will be needed, but then adding new vendors or micro-architectures will not require breaking changes as they would otherwise have.

Is this breaking change (due to non_exhaustive attribute on vendor) necessary? If not, it might be better to have at least one version without breaking changes (minor version update). Then, introduce this breaking change with major version update?

GuillaumeDIDIER commented 4 months ago

Note, because adding more vendor in the future seems possible, I've marked the Vendor enum as non_exhaustive, and all the micro-architecture ones will also be non_exhaustive. This is a breaking change for users, a major version will be needed, but then adding new vendors or micro-architectures will not require breaking changes as they would otherwise have.

Is this breaking change (due to non_exhaustive attribute on vendor) necessary? If not, it might be better to have at least one version without breaking changes (minor version update). Then, introduce this breaking change with major version update?

I think currently the vendor enum is not public, which should make it non breaking (but I am not confident about it).

If it is, however, I agree with splitting this into 2 steps.