Hi Stas,
On Wed, 2017-06-07 at 21:54 +0300, Stas Sergeev wrote:
> Hi Ricardo, would you mind unsubscribing
> linux-msdos@ from all your future mails on
> this subject? Otherwise I am afraid there
> would be no subscribers left when you are
> finally done. :)
Sure! I will drop linux-msdos in the
Hi Ricardo, would you mind unsubscribing
linux-msdos@ from all your future mails on
this subject? Otherwise I am afraid there
would be no subscribers left when you are
finally done. :)
I think all non-kernel-dev MLs should be
treated with more care. Eg your initial
questions were certainly
On Tue, Jun 06, 2017 at 05:28:52PM -0700, Ricardo Neri wrote:
> I see. You were more concerned about the naming of the coding artifacts
> (e.g., function names, error prints, etc) than the actual filenames.
Well, I'm not sure here. We could either have a generalized prefix or
put the function
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
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
On Mon, 2017-05-29 at 18:37 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:05AM -0700, Ricardo Neri wrote:
> > We are not in a critical failure path. The invalid register type is caused
> > when trying to decode invalid instruction bytes from a user-space program.
> > Thus, simply
On Fri, May 05, 2017 at 11:17:05AM -0700, Ricardo Neri wrote:
> We are not in a critical failure path. The invalid register type is caused
> when trying to decode invalid instruction bytes from a user-space program.
> Thus, simply print an error message. To prevent this warning from being
> abused
We are not in a critical failure path. The invalid register type is caused
when trying to decode invalid instruction bytes from a user-space program.
Thus, simply print an error message. To prevent this warning from being
abused from user space programs, use the rate-limited variant of printk.