Aren't we overthinking / overdesigning this a bit? It's not rocke
science. We'd like to have a leaf set aside for TSC frequency, and
maybe another leaf in the future. We think other vendors might find a
static clock frequency leaf to be useful, so if that happens to be the
case, feel free to re-use the leaf.
We don't expect to see lots of proliferation of CPU leaves at all, in
fact, we'd be flummoxed to propose more than one right now. So
basically a nicely written comment section explaining how the SW CPUID
registers are layed out is probably sufficient. Other vendors can add
to it as they see fit, and Linux itself can be the central standard
body. After all, it's what we all work on, and it makes sense for
everyone here, even MS, to have the software leaves defined in a public
work.
The whole thing is software defined so it's not a big deal if one or all
parties eventually don't play well with others, grow up to become
bullies with ADD, or simply autistic children who ignore the whole
thing. You can always make detection vendor dependent when that
happens.
Right now there's nothing shockingly vendor dependent, just a whole lot
of complicated proposals about how to define what the bits are going to
define and not enough bits of information to actually express. It seems
perfectly okay for now to have new leaf proposals defined by fiat for
now.
As long as there is a vendor-ID leaf, nobody is blocking any forward
progress by adding a new non-conflicting leaf. We can always add the
meta-leafs required for decoding if something tangible materializes, but
for now the TSC leaf seems pretty useful and I would probably want to
proclaim it by fatwa, if I had such a power.