From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Subject: Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register
 type
Date: Tue, 06 Jun 2017 17:28:52 -0700
Message-ID: <1496795332.24288.89.camel@ranerica-desktop>
References: <20170505181724.55000-1-ricardo.neri-calderon@linux.intel.com>
         <20170505181724.55000-8-ricardo.neri-calderon@linux.intel.com>
         <20170529163748.bmihhr4j3hznbhcn@pd.tnic>
         <1496729218.24288.82.camel@ranerica-desktop>
         <20170606115842.ei3uowcgxwta2v5g@pd.tnic>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20170606115842.ei3uowcgxwta2v5g@pd.tnic>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-msdos.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Borislav Petkov <bp@suse.de>
Cc: Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Andrew Morton <akpm@linux-foundation.org>, Brian Gerst <brgerst@gmail.com>, Chris Metcalf <cmetcalf@mellanox.com>, Dave Hansen <dave.hansen@linux.intel.com>, Paolo Bonzini <pbonzini@redhat.com>, Masami Hiramatsu <mhiramat@kernel.org>, Huang Rui <ray.huang@amd.com>, Jiri Slaby <jslaby@suse.cz>, Jonathan Corbet <corbet@lwn.net>, "Michael S. Tsirkin" <mst@redhat.com>, Paul Gortmaker <paul.gortmaker@windriver.com>, Vlastimil Babka <vbabka@suse.cz>, Chen Yucong <slaoub@gmail.com>, Alexandre Julliard <julliard@winehq.org>, Stas Sergeev <stsp@list.ru>, Fenghua Yu <fenghua.yu>

On Tue, 2017-06-06 at 13:58 +0200, Borislav Petkov wrote:
> On Mon, Jun 05, 2017 at 11:06:58PM -0700, Ricardo Neri wrote:
> > I agree that insn-eval reads somewhat funny. I did not want to go with
> > insn-dec.c as insn.c, in my opinion, already decodes the instruction
> > (i.e., it finds prefixes, opcodes, ModRM, SIB and displacement bytes).
> > In insn-eval.c I simply take those decoded parameters and evaluate them
> > to obtain the values they contain (e.g., a specific memory location).
> > Perhaps, insn-resolve.c could be a better name? Or maybe isnn-operands?
> 
> So actually I'm gravitating towards calling all that instruction
> "massaging" code with a single prefix to denote this comes from the insn
> decoder/handler/whatever...
> 
> I.e.,
> 
> 	"insn-decoder: x86: invalid register type"
> 
> or
> 
> 	"inat: x86: invalid register type"
> 
> or something to that effect.
> 
> I mean, If we're going to grow our own - as we do, apparently - maybe it
> all should be a separate entity with its proper name.

I see. You were more concerned about the naming of the coding artifacts
(e.g., function names, error prints, etc) than the actual filenames. I
think I have aligned with the function naming of insn.c in all the
functions that are exposed via header by using the inns_ prefix. For
static functions I don't use that prefix. Perhaps I can use the __
prefix as insn.c does.

Thanks and BR,
Ricardo