lkml.org 
[lkml]   [2016]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v2] x86: Add an archinfo dumper module
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.

\
 
 \ /
  Last update: 2016-02-09 21:21    [W:0.075 / U:9.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site