2014-09-18 09:19+0200, Borislav Petkov: > On Thu, Sep 18, 2014 at 02:29:54AM +0200, Radim Krčmář wrote: > > I think you proposed to use magic constant in place of of MASK_FAM_X, so > > Huh, what? Your example. It cannot be verbatim MASK_FAM_X in real code. I interpreted it to be a placeholder for 0x1ffff (first 17 bits) and said why I think it is not a good thing. The other interpretation (well named macro) was against your goal. > > Second problem: Most elements don't begin at offset 0, so the usual > > retrieval would add a shift, (repurposing max_monitor_line_size) > > So what? Your goal was easy parsing (last sentence of the mail). My argument is that bitfields are easier to read. (With examples.) > > max_monitor_line_size = (cpuid & MASK_FAM_X) >> OFFSET_FAM_X; > > > > and it's not better when we write it back after doing stuff. > > Writing back CPUID on baremetal? You can't be serious. We are not talking just about baremetal, see patch [3/3]. There are, and will be new, use cases for modifying and storing cpuid. > Ok, this is getting ridiculous so I'll stop wasting time. I stand by my > initial statement - this is a bad idea. Acknowledged. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
