public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Roland McGrath <roland@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH x86/mm 08/11] x86 ia32 ptrace getreg/putreg merge
Date: Thu, 29 Nov 2007 20:50:32 +0100	[thread overview]
Message-ID: <20071129195032.GC15245@elte.hu> (raw)
In-Reply-To: <474EFDF8.8090506@zytor.com>


* H. Peter Anvin <hpa@zytor.com> wrote:

> Christoph Hellwig wrote:
>> On Thu, Nov 29, 2007 at 04:00:31AM -0800, Roland McGrath wrote:
>>> +#define R32(l,q)							\
>>> +	case offsetof(struct user32, regs.l):				\
>>> +		regs->q = value; break
>>> +
>>> +#define SEG32(rs)							\
>>> +	case offsetof(struct user32, regs.rs):				\
>>> +		return set_segment_reg(child,				\
>>> +				       offsetof(struct user_regs_struct, rs), \
>>> +				       value);				\
>>> +		break
>>
>> The code would be a lot more readable if you just opencoded this in the
>> caller instead of these obsfucated macros.
>
> For better or worse, though, that is style of existing code.  I 
> personally found it easy to deal with when I went through the code 
> recently.

yep. The ptrace code has certainly lots of inconsistent style crap piled 
up during its 10 year history of only be touched with a 10 foot pole. 
I'd go for small patches that continuously improve the picture within 
the existing mechanisms than any "100% pure required" approach. With 48 
clean patches from Roland we are already on the right granularity level 
i think.

See how ptrace.c raw code quality has already increased leaps and 
bounds:

                                       errors   lines of code   errors/KLOC
 [before]
 arch/x86/kernel/ptrace_64.c               58             621          93.3
 arch/x86/kernel/ptrace_32.c               39             717          54.3

 [after]
 arch/x86/kernel/ptrace.c                  13            1135          11.4

so i'm not worried about that aspect. We are definitely "for the 
better".

	Ingo

  reply	other threads:[~2007-11-29 19:51 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29 11:57 [PATCH x86/mm 01/11] x86-32 thread_struct.debugreg Roland McGrath
2007-11-29 11:59 ` [PATCH x86/mm 02/11] x86: ptrace_32 renamed Roland McGrath
2007-11-29 11:59 ` [PATCH x86/mm 03/11] x86: ptrace FLAG_MASK cleanup Roland McGrath
2007-11-29 11:59 ` [PATCH x86/mm 04/11] x86 ptrace getreg/putreg cleanup Roland McGrath
2007-11-29 11:59 ` [PATCH x86/mm 05/11] x86 ptrace getreg/putreg merge Roland McGrath
2007-11-29 17:27   ` Andrew Morton
2007-11-29 22:28     ` Roland McGrath
2007-11-30 11:40       ` Ingo Molnar
2007-11-29 12:00 ` [PATCH x86/mm 06/11] x86 ptrace arch merge Roland McGrath
2007-11-29 17:28   ` Andrew Morton
2007-11-29 21:33     ` Roland McGrath
2007-11-29 12:00 ` [PATCH x86/mm 07/11] x86 ptrace merge syscall trace Roland McGrath
2007-11-29 12:00 ` [PATCH x86/mm 08/11] x86 ia32 ptrace getreg/putreg merge Roland McGrath
2007-11-29 17:37   ` Christoph Hellwig
2007-11-29 17:59     ` H. Peter Anvin
2007-11-29 19:50       ` Ingo Molnar [this message]
2007-11-29 12:00 ` [PATCH x86/mm 09/11] x86 ia32 ptrace arch merge Roland McGrath
2007-11-29 20:58   ` Alexey Dobriyan
2007-11-29 21:37     ` Roland McGrath
2007-11-30 11:34       ` Ingo Molnar
2007-11-29 12:00 ` [PATCH x86/mm 10/11] x86 ptrace merge complete Roland McGrath
2007-11-29 12:00 ` [PATCH x86/mm 11/11] x86 ptrace merge removals Roland McGrath
2007-11-29 14:04   ` Jeff Dike
2007-11-29 22:38     ` Roland McGrath
2007-11-30  0:03       ` Jeff Dike
2007-11-29 12:23 ` [PATCH x86/mm 01/11] x86-32 thread_struct.debugreg Ingo Molnar
2007-11-29 21:50   ` Roland McGrath
2007-11-29 23:02     ` Chuck Ebbert
2007-11-30  0:07     ` Jeff Dike

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071129195032.GC15245@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox