All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86: fault_{32|64}.c unify do_page_fault
Date: Wed, 02 Jan 2008 19:51:21 -0800	[thread overview]
Message-ID: <477C5BB9.7020106@zytor.com> (raw)
In-Reply-To: <1199326158.6323.87.camel@brick>

Harvey Harrison wrote:
> 
> My apologies, testing/compiling on X86_32 here.
> 
>> Do you seriously think code is getting better and more readable because
>> of this liberal #ifdef sprinkling in every possible direction?
>>
> 
> Well, this of course is not the end of the road, but it makes it
> obvious where the differences between 32/64 bit lie and allows
> further cleanups to unify these areas over time.  This is meant as
> a no functionality change path at first.....and it does point out that
> for the most part the files are _very_ similar to each other.
> 
> So my plan for now was to move forward with no functional changes and
> esentially ifdef or reorder code until we get to identical fault_32/64.c
> which then gets moved to a single fault.c
> 
> Then the cleanups happen in one place in one file and it should be easy
> to audit the series at the end.  But for further patches I'll wait until
> the series is further along and tested before submitting.  This was how
> the kprobes unification went and I think it works fairly well this way.
> 

One more thing... for code motion/unification patches it's a good thing 
to verify that the i386 and x86-64 binaries are both unchanged.

	-hpa

      parent reply	other threads:[~2008-01-03  3:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-03  1:01 [PATCH] x86: fault_{32|64}.c unify do_page_fault Harvey Harrison
2008-01-03  1:45 ` Alexey Dobriyan
2008-01-03  2:09   ` Harvey Harrison
2008-01-03  2:30     ` H. Peter Anvin
2008-01-03  3:51     ` H. Peter Anvin [this message]

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=477C5BB9.7020106@zytor.com \
    --to=hpa@zytor.com \
    --cc=adobriyan@gmail.com \
    --cc=harvey.harrison@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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.