All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olof Johansson <olof@lixom.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Steve Munroe <sjmunroe@us.ibm.com>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Paul Mackerras <paulus@samba.org>,
	Olof Johansson <olof@lixom.net>,
	cbe-oss-dev@ozlabs.org
Subject: Re: Cell and new CPU feature bits
Date: Fri, 26 May 2006 08:16:49 -0700	[thread overview]
Message-ID: <20060526151649.GA5067@pb15.lixom.net> (raw)
In-Reply-To: <1148628831.8089.107.camel@localhost.localdomain>

On Fri, May 26, 2006 at 05:33:51PM +1000, Benjamin Herrenschmidt wrote:

> > Do we see this likely to be used in "global userspace", or more likely
> > in the processor-specific glibc sections? If it's in the
> > processor-specific ones, maybe we should have a per-processor bitfield
> > with erratas/features instead of a global one. That'd make allocation
> > easier too.
> 
> Do we have to deal with that many errata that affect userland ? It's
> generally an area where processors are fairly well validated... I don't
> think we need to scale up that much on this one.

Right, amount of erratas should be limited. BUt the amount of features
can be larger, especially as they grow over time and never go away.

> > > Yes, I think a new CPU feature bit for that too is needed. Not much of
> > > these left...
> > 
> > Well, are these instructions architected in some later version past
> > 2.02? If so, the bit is only needed on the older processors -- yet again
> > a case for sub-feature/errata bitmasks.
> 
> I have to check but I suspect it's still optional.

Ok. Features like that tend to be implementation-specific in the firt
processor they show up in, and later make it into the architecture.
That's why I'm asking. :-)

-Olof

  reply	other threads:[~2006-05-26 15:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-19  4:07 Cell and new CPU feature bits Benjamin Herrenschmidt
2006-05-19  5:19 ` Olof Johansson
2006-05-19  5:27   ` [Cbe-oss-dev] " Andrew Pinski
2006-05-19  7:49     ` Segher Boessenkool
2006-05-26  6:19     ` Benjamin Herrenschmidt
2006-05-26  6:19   ` Benjamin Herrenschmidt
2006-05-26  6:43     ` Olof Johansson
2006-05-26  7:33       ` Benjamin Herrenschmidt
2006-05-26 15:16         ` Olof Johansson [this message]
2006-05-19  8:16 ` Gabriel Paubert
2006-05-22 19:46   ` [Cbe-oss-dev] " Alex Rosenberg
2006-05-23 21:52     ` Benjamin Herrenschmidt
2006-05-26  6:22   ` Benjamin Herrenschmidt
2006-05-19 10:11 ` [Cbe-oss-dev] " Arnd Bergmann
2006-05-19 16:18   ` Olof Johansson
2006-05-19 22:33     ` Paul Mackerras
2006-05-26  6:22   ` [Cbe-oss-dev] " Benjamin Herrenschmidt

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=20060526151649.GA5067@pb15.lixom.net \
    --to=olof@lixom.net \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=sjmunroe@us.ibm.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 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.