What about documentation?
It seems to me for the usual user, it will be unclear what CPU features have(excluding what was described in README samples).
I would like to propose to introduce documentation that will include the API documentation e.g. Doxygen with GitHub pages or Github Wiki.
typedef struct {
X86Features features;
int family;
int model;
int stepping;
char vendor[13];
} X86Info;
Description of structures, what they contain, what each field defined.
Also, it will be great to make it clear what is supported. For example:
AMD CPUID supports:
- [x] CPUID Fn0000_0000_E[D,C,B]X Processor Vendor
- [ ] CPUID Fn8000_001E_E[D,C,B]X Compute Unit Identifiers
- [ ] CPUID Fn8000_001E_EAX Extended APIC ID
Thx for the issue. I agree that more documentation would be appreciated, especially in the headers. So let's start with documenting each field there.
Now, I'm not too fond of Doxygen in this case.
- For the public API : documenting the header should suffice.
- For the implementation : the code relies on macros to provide different logic for different combinations of CPU x OS. This means that we should run Doxygen for each case and gather the documentations somehow. This feels like a lot of effort and I'm not sure we have the bandwidth to support this.
I understand the need but I don't have a good alternative apart from structuring the code in a way that makes it obvious what we support. We could definitely improve on that front.
Let me know what you think.
Ok, what about creating a documentation site like googletest with guides, changelog, references for contributors. I created simple docs using VuePress cpu_features_test_docs, implementation link: test_branch
@gchatelet
I also agree that the document is required How can I know the public API information? I am looking for a bug in open source and report a bug in the open source, so I need a list of cpu_feature APIs. Where can I know?
gentle ping @gchatelet