mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	akpm@osdl.org, ak@suse.de, linux-kernel@vger.kernel.org,
	davej@redhat.com
Subject: Re: common code between i386 and x86_64 (was Re: [Patch] share i386/x86_64 intel cache descriptors table)
Date: Thu, 7 Oct 2004 11:50:30 +0200	[thread overview]
Message-ID: <20041007095030.GB21807@wotan.suse.de> (raw)
In-Reply-To: <20041007002550.A12738@unix-os.sc.intel.com>

On Thu, Oct 07, 2004 at 12:25:50AM -0700, Siddha, Suresh B wrote:
> On Wed, Oct 06, 2004 at 11:25:14PM -0400, Jeff Garzik wrote:
> > 
> > I have often wondered if there is any value to creating arch/x86 and 
> > include/asm-x86 for stuff shared between x86-64 and i386.
> 
> Yes. There is definitely some value. Currently this kind of code is scattered
> all around the place. With this demarcation, people touching this common
> code will be careful of not breaking arch's that are sharing this code.

The current method of just linking between arch/i386 and arch/x86_64
works fine IMHO. No need to get any fancier. Doing a large scale
rename would just have the effect of breaking any 3rd party patchkits
and making merging even more difficult. I doubt it would
improve the maintainability much.

I don't think they will be more careful just because the code is
in a separate directory. The only way to enforce both work is
to compile and test both.


> We can avoid duplicate data structure definitions and duplicate prototypes.

Possible a few more includes could be shared, but the advantage 
is probably not big. I don't think it makes sense to share
includes when the main code is not shared.

Also in some ways x86 and x86-64 are diverging more and more, so
sharing becomes more difficult. e.g. long ago I actually applied
a lot of patches with sed s/i386/x86_64/g. But these days most
things need to be ported by hand. And most stuff that can 
be trivially shared is already shared. Doing significantly
more sharing would need more changes to arch/i386, and I still
don't see much support for that. Also in some cases I expect
code to diverge even more, so having a bit less is not a bad thing.

-Andi

  reply	other threads:[~2004-10-07  9:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-07  1:47 [Patch] share i386/x86_64 intel cache descriptors table Suresh Siddha
2004-10-07  3:25 ` Jeff Garzik
2004-10-07  5:22   ` Willy Tarreau
2004-10-07  7:25   ` common code between i386 and x86_64 (was Re: [Patch] share i386/x86_64 intel cache descriptors table) Suresh Siddha
2004-10-07  9:50     ` Andi Kleen [this message]
2004-10-07  9:54 ` [Patch] share i386/x86_64 intel cache descriptors table Andi Kleen

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=20041007095030.GB21807@wotan.suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=davej@redhat.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    /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

all inboxes | Powered by JetHome®