From: Ralf Baechle <ralf@oss.sgi.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Carsten Langgaard <carstenl@mips.com>, linux-mips@oss.sgi.com
Subject: Re: 64 bit build fails
Date: Fri, 15 Dec 2000 16:32:08 +0100 [thread overview]
Message-ID: <20001215163208.D28594@bacchus.dhis.org> (raw)
In-Reply-To: <007001c06670$7345d2e0$0deca8c0@Ulysses>; from kevink@mips.com on Fri, Dec 15, 2000 at 09:24:22AM +0100
On Fri, Dec 15, 2000 at 09:24:22AM +0100, Kevin D. Kissell wrote:
> In the absence of the SGI people being directed to do a
> clean job, I suppose the problem falls to those who have
> an interest in a clean and portable 64-bit MIPS kernel.
> That would include MIPS, of course. But what about the
> rest of you - could we see a show of virtual hands? I
> know that TI has both 4K and 5K licenses, and may
> want to be able to exploit the 64-bit capability of the 5K
> under Linux. And the guys doing the Vr41xx ports may
> also be interested. Anyone else? Those of you with
> R4K-based DECstations, perhaps? Software shops
> looking to support high-end embedded MIPS in set-tops?
>
> Another aspect of this is that, in the newer MIPS
> designs that conform to the MIPS64 architecture spec,
> it is finally possible to cleanly seperate the use of
> 64-bit data types from the use of 64-bit virtual addresses.
> The processors in the SGI platforms do not have this
> capability, and it would be a lot to ask of the people
> doing 64-bit Linux for Origin etc. to treat the addressing
> and data aspects orthogonally. I haven't checked the
> code, but I would imagine that we will have to go in
> and redo things from that perspective as well.
That's one of the plans I have; even in the absense of these new MIPS64
features separation of these new features makes sense. One of the plans
on my agenda is for example the introduction of 2-level pagetables for
mips64 which will eleminate much of the extra price the 64-bit kernel
currently has to pay.
Ralf
next prev parent reply other threads:[~2000-12-15 15:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-13 15:58 64 bit build fails Carsten Langgaard
2000-12-14 20:59 ` Ralf Baechle
2000-12-15 7:45 ` Carsten Langgaard
2000-12-15 8:24 ` Kevin D. Kissell
2000-12-15 8:24 ` Kevin D. Kissell
2000-12-15 15:32 ` Ralf Baechle [this message]
2000-12-15 22:28 ` PianoMan
2000-12-15 15:20 ` Ralf Baechle
2000-12-18 8:11 ` Carsten Langgaard
2000-12-19 17:47 ` Ralf Baechle
2000-12-17 20:19 ` Thiemo Seufer
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=20001215163208.D28594@bacchus.dhis.org \
--to=ralf@oss.sgi.com \
--cc=carstenl@mips.com \
--cc=kevink@mips.com \
--cc=linux-mips@oss.sgi.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