On Tue, Nov 18, 2014 at 4:43 PM, Borislav Petkov <[email protected]> wrote: > On Tue, Nov 18, 2014 at 04:29:59PM +0100, Stephane Eranian wrote: >> I am trying to get a better understanding of this scheme. >> >> status: >> - a summary of what is enabled/disabled? >> - With description (as suggested by Boris)? >> - File is readonly >> - is that printing a variable length bitmask? > > Should be the easiest. Maybe extend/add to the X86_BUG() functionality > in arch/x86/include/asm/cpufeature.h which already deals with CPU bugs. > Does it need to bit a bitmask, as opposed to just a bug number (which could be implemented as a bitmask)?
>> enable_workaround: >> - provide the bit number (of the workaround) to enable the workaround > > Right, writing the bit number could be part of the description message > above - just so that users know how to control the interface. > writing the bug number.... >> - File is write-only >> >> disable_workaround: >> - provide the bit number (of the workaround) to disable the workaround >> - File is write-only >> >> The split enable/disable is to avoid the read-modify-write issue. >> >> Am I getting this right? >> >> I understand the value of this proposition. But, I feel, it is beyond the >> scope >> of the patch series to workaround the PMU bug. Initially, we had >> talked about not >> even providing the sysfs file. Now, the series adjusts the workaround >> on boot. The series is restructured so that the sysfs patch is the last >> one and is totally optional. I think we should implement the proposed scheme >> but we should not delay the review and merge of the rest of the patch series >> for this. But I can propose a separate patch series to implement the proposed >> scheme. > > Right, IMHO, we can always add sysfs structure later, when its design is > sane. What we should absolutely avoid is exposing something to userspace > now and then try to hide it/replace it with something else and break > userspace, which, as we all know, is a no-no, punishable by Linus coming > to your house with a bat. > I am okay with this approach. > :-) :-) > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
