Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Johannes Stezenbach <js@convergence.de>
To: Daniel Jacobowitz <dan@debian.org>
Cc: "Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
Subject: Re: Once again: test_and_set for CPUs w/o LL/SC
Date: Tue, 15 Oct 2002 19:52:05 +0200	[thread overview]
Message-ID: <20021015175205.GA21538@convergence.de> (raw)
In-Reply-To: <20021007185136.GA16501@nevyn.them.org>

On Mon, Oct 07, 2002 at 02:51:36PM -0400, Daniel Jacobowitz wrote:
> On Mon, Oct 07, 2002 at 08:43:44PM +0200, Johannes Stezenbach wrote:
> > The question is how the glibc can detect if
> > a) the CPU does not have LL/SC
> > b) the kernel guarantees k1 != MAGIC
> 
> You should be using an "aux vector"; see how PowerPC provides current
> glibc with the size of a cache line.

It took me a while to figure out how aux vectors work.

It seems to me that MIPS does not use the hardware capabilities
field of the aux vector at all. TO use it, one would
have to

- add a field to struct cpuinfo_mips in include/asm-mips/processor.h,
  and set it in arch/mips/kernel/setup.c after CPU probing;
- define ELF_HWCAP in include/asm-mips/elf.h to return
  something useful from the new cpuinfo_mips field

Or, to just use it to signal "use beql k1, MAGIC instead of LL/SC",
one could just define ELF_HWCAP dependent on kernel-Config.

Anyway, we would have to document the meaning of the HWCAP bits
as part of the kernel ABI.

i386 uses this, as you can see by running e.g.
  $ LD_SHOW_AUXV=1 ls
provided you have glibc-2.2.5.

glibc/sysdeps/generic/dl-sysdep.c then reads it into dl_hwcap,
and it's up to platform specific code to use it.


Regards,
Johannes

  reply	other threads:[~2002-10-15 17:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-16 16:40 Once again: test_and_set for CPUs w/o LL/SC Johannes Stezenbach
2002-10-07 14:47 ` Johannes Stezenbach
2002-10-07 16:21   ` Kevin D. Kissell
2002-10-07 16:21     ` Kevin D. Kissell
2002-10-07 18:43     ` Johannes Stezenbach
2002-10-07 18:51       ` Daniel Jacobowitz
2002-10-15 17:52         ` Johannes Stezenbach [this message]
2002-10-08  7:38       ` Kevin D. Kissell
2002-10-08  7:38         ` Kevin D. Kissell
2002-10-15 15:36       ` Maciej W. Rozycki
2002-10-15 17:21         ` Johannes Stezenbach
2002-10-16 12:20           ` Maciej W. Rozycki
2002-10-16 12:52             ` Johannes Stezenbach
2002-10-16 16:30               ` Johannes Stezenbach
2002-10-17  9:47                 ` Gleb O. Raiko
2002-10-17 12:02                   ` Maciej W. Rozycki
2002-10-17 13:11                     ` Johannes Stezenbach
2002-10-17 13:32                       ` Gleb O. Raiko
2002-10-17 14:13                         ` Johannes Stezenbach
2002-10-16 18:11         ` Johannes Stezenbach
2002-10-16 18:23           ` Johannes Stezenbach
2002-10-17 11:57           ` Maciej W. Rozycki
2002-10-17 13:25             ` Johannes Stezenbach
2002-10-15 15:17     ` Maciej W. Rozycki
2002-10-15 16:50       ` Johannes Stezenbach

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=20021015175205.GA21538@convergence.de \
    --to=js@convergence.de \
    --cc=dan@debian.org \
    --cc=kevink@mips.com \
    --cc=linux-mips@linux-mips.org \
    /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