lkml.org 
[lkml]   [2015]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] x86/asm/entry/32: Open-code CLEAR_RREGS. No code changes.

* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 2 Jun 2015 21:04:01 +0200
> Denys Vlasenko <dvlasenk@redhat.com> wrote:
>
> > This macro is small, has only four callsites, and one of them is slightly
> > different using a conditional parameter.
> >
> > A few saved lines aren't worth the resulting obfuscation.
>
> I'm curious, why? Did someone recommend this change? I don't see it as
> obfuscation at all.

So here are a few easy questions, I'm wondering how many minutes it takes for you
to answer them correctly:

- What does the CLEAR_RREGS name stand for?

- What is this macro's purpose?

- In a single case CLEAR_RREGS takes a 'r9' argument:

arch/x86/ia32/ia32entry.S: CLEAR_RREGS
arch/x86/ia32/ia32entry.S: CLEAR_RREGS
arch/x86/ia32/ia32entry.S: CLEAR_RREGS r9
arch/x86/ia32/ia32entry.S: CLEAR_RREGS
arch/x86/ia32/ia32entry.S: CLEAR_RREGS

What is the 'r9' argument's purpose and why is activated in the place where
it's activated?

The CLEAR_RREGS macro has zero comments. If it takes more than a quick glance to
determine all these three first-order questions from the source code, then it's an
obvious code cleanliness fail which needs to be improved.

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-06-03 09:21    [W:0.070 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site