On Fri, Sep 19, 2014 at 03:40:29PM +0200, Paolo Bonzini wrote: > And similarly, Intel would not extend a bit from 16 to 17 bits if it > weren't zero on all older processors.
Nothing is stopping a hw designer to say we're using 17 bits now. And software needs to deal with that. It is that simple! > > However, even there > > > > "16 - Reserved - Do not count on the value." > > > > I'm quoting Intel's CPUID doc 241618-037 from 2011 (there might be a > > newer one though), the CPUID(1).ECX description. > > Once that bit gets a meaning in newer processors, the same meaning will > work retroactively for existing processors. That's just how CPUID is > used. Nobody checks families before testing bits, Intel/AMD do not even > suggest that. I know that, and I bet those bits won't even get reused but we don't know, do we?! All I'm pointing at is that even the feature bits which are reserved cannot be relied to be of any value. In any case, the moment hw designers decide to change any field width for which you have an union defined, this fragile scheme breaks with you needing to introduce ifdeffery. And frankly, this whole waste-time discussion is only about you guys wanting to use those bitfields so that constructing a CPUID value works more conveniently. (Reportedly, I'm not convinced of that at all). While the gazillion other places in the kernel simply use logical operations to construct a value and write it into the corresponding register. Does that mean that they have to go and define unions for those registers too? Of course not! That would be insane. I remember a time where we did remove exactly that type of bitfields from the ide code because it wasn't helping, it was counter-intuitive and needless. Geez, can we drop this already! It is a dumb idea, it doesn't bring us anything besides some superficial readability which you don't really need. Nowadays you can use even goddam wikipedia to understand what the CPUID bits mean: https://en.wikipedia.org/wiki/CPUID Everytime we have to access registers, we need to open the corresponding manual (or wikipedia, alternatively :-)) and look at the bit definitions. This will not change. > > Do you have a guarantee that this won't happen in the future and break > > all your fancy bitfields assumptions? > > No guarantee, but were that to happen, I'd expect tar and feathers > spectacles around Intel's engineering headquarters. You're going over and doing some fireworks there? :-P -- Regards/Gruss, Boris. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
