Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1330612

Re: [PATCH -v2] x86: Add an archinfo dumper module

Show all headers | View raw

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.

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH -v2] x86: Add an archinfo dumper module "Luck, Tony" <tony.luck@intel.com> - 2016-02-09 20:20 +0100
  Re: [PATCH -v2] x86: Add an archinfo dumper module Borislav Petkov <bp@alien8.de> - 2016-02-09 20:50 +0100

csiph-web