From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755077AbcBITrA (ORCPT ); Tue, 9 Feb 2016 14:47:00 -0500 Received: from mail.skyhub.de ([78.46.96.112]:51487 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753351AbcBITq7 (ORCPT ); Tue, 9 Feb 2016 14:46:59 -0500 Date: Tue, 9 Feb 2016 20:46:55 +0100 From: Borislav Petkov To: "Luck, Tony" Cc: Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Andy Lutomirski , Peter Zijlstra , Steven Rostedt , Brian Gerst , lkml Subject: Re: [PATCH -v2] x86: Add an archinfo dumper module Message-ID: <20160209194655.GF4119@pd.tnic> References: <20160201115601.GD6438@pd.tnic> <3908561D78D1C84285E8C5FCA982C28F39FCE0E4@ORSMSX114.amr.corp.intel.com> <20160202094147.GA3778@pd.tnic> <20160203104823.GA21257@gmail.com> <20160203110052.GA20682@pd.tnic> <20160204152235.GB5343@pd.tnic> <20160204190757.GA4249@agluck-desk.sc.intel.com> <20160207105103.GC5862@pd.tnic> <20160209191758.GA21766@agluck-desk.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160209191758.GA21766@agluck-desk.sc.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 09, 2016 at 11:17:59AM -0800, Luck, Tony wrote: > There is a lot of bit counting and typing either way. My string > format is visually compact, and looks quite similar to the eventual > output. Except if you have 64 all single bits and all defined. Then that thing: +static char *cr4_format = +"41r|PKE|SMAP|SMEP|1r|OSXSAVE|PCIDE|FSGSBASE|1r|SMXE|VMXE|2r|OSXMMEXCPT|OSFXSR|PCE|PGE|MCE|PAE|PSE|DE|TSD|PVI|VME"; triples. The array approach is going to be long too but in the vertical and still visually parseable. > Your reg_range does allow you to pass counting to the compiler > in the case that the documentation gives you highbit/lowbit > ranges. But most fields are small enough that yuo don't even > need to take your socks off to count ... so I don't see it as > a huge deal. > > Both formats allow for a sanity check that all the bitfields > add up to 64 ... which will detect single errors (which your > code for my example would fail because you missed the second > reserved field) and only have 60 bits described). The code iterating over reg_descriptor can check that, of course. So the only thing I'm trying to avoid is string parsing - if you add all the corner cases handling and more field syntax, then the whole parsing game could become pretty complex and maybe even fragile. Not with the range descriptors - that remains simple. And I like simple. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.