From: "Kevin D. Kissell" <kevink@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com,
Ralf Baechle <ralf@uni-koblenz.de>
Subject: Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64
Date: Tue, 23 Jul 2002 14:13:10 -0700 [thread overview]
Message-ID: <3D3DC6E6.AFF9CBFD@mips.com> (raw)
In-Reply-To: Pine.GSO.3.96.1020723164235.29699A-100000@delta.ds2.pg.gda.pl
> > My personal belief is that the mips and mips64 trees
> > should ultimately be merged, and that creating additional
> > and gratuitous differences should be avoided.
>
> I don't think it's possible to be fully achieved. Some differences will
> have to exist, at least in the headers, but likely within the arch tree as
> well. The reason is binary code size or perfomance -- having R3000
> support code in mips64 binaries is simply ridiculous as is using 32-bit
> operations with 64-bit data on a 64-bit CPU. However, it is worth trying
> to minimize visible differences where possible, e.g. by convincing the
> compiler to optimize irrelevant bits away.
I am not interested in running R3000's with 64-bit
binaries - only in having common sources for both.
I fully expect that there will always be differences
between the platforms, but the last time I checked,
there were more identical or nearly identical source
modules across the two arch trees than there were
distinctly different ones. The result is that the
two subtrees tend to drift out of sync. For me,
it's really a "Software Engineering 101" kind of
thing that there should be exactly one instance
in the source tree of any source module that is
common to 32-bit and 64-bit MIPS kernels, and that
where the code cannot be common, sensible rules should
be applied in terms of when to put both sets of code
in the same module as conditionally complied blocks and
when to split things out into seperately maintained
modules. Etc. Etc.
Kevin K.
next prev parent reply other threads:[~2002-07-23 21:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-23 11:55 [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64 Maciej W. Rozycki
2002-07-23 12:14 ` Ralf Baechle
2002-07-23 13:05 ` Maciej W. Rozycki
2002-07-23 13:23 ` Ralf Baechle
2002-07-23 13:31 ` Maciej W. Rozycki
2002-07-23 13:59 ` Ralf Baechle
2002-07-23 18:20 ` Jun Sun
2002-07-24 15:11 ` Maciej W. Rozycki
2002-07-23 14:38 ` Kevin D. Kissell
2002-07-23 14:38 ` Kevin D. Kissell
2002-07-23 14:49 ` Ralf Baechle
2002-07-23 16:00 ` Maciej W. Rozycki
2002-07-23 21:13 ` Kevin D. Kissell [this message]
2002-07-24 14:52 ` Ralf Baechle
2002-07-24 15:05 ` Maciej W. Rozycki
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=3D3DC6E6.AFF9CBFD@mips.com \
--to=kevink@mips.com \
--cc=linux-mips@fnet.fr \
--cc=linux-mips@oss.sgi.com \
--cc=macro@ds2.pg.gda.pl \
--cc=ralf@uni-koblenz.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox