All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.