All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominic Sweetman <dom@mips.com>
To: Jun Sun <jsun@mvista.com>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: anybody tried NPTL?
Date: Fri, 20 Aug 2004 14:46:11 +0100	[thread overview]
Message-ID: <16678.163.774841.111369@arsenal.mips.com> (raw)
In-Reply-To: <20040819221646.GC8737@mvista.com>


Jun Sun (jsun@mvista.com) writes:

> > [large expanse of new ABI stuff omitted]
>
> What is the motivation of other changes?  Taking this chance to make
> things all right in one shot?

Yes, and I did kind of cover this in the large expanse of stuff:

> > As you said, this motivates a revision of the ABI.  Any
> > incompatible change to the ABI is painful, since everything has to
> > be recompiled; so our reasoning at the moment is that we might as
> > well be radical...

o32 puts only four arguments in registers, which is less than optimal,
and continually reloads the GOT pointer (which is not defined as a
saved register in o32).

n32 (despite its name) runs exclusively on 64-bit CPUs.

So yes, we have strong reasons for making a larger change to the ABI,
and knowing how difficult it is...

> However, from NPTL implementation point of view I really just care
> about the per-thread register.

I guess our main message was that we felt it would be a mistake just
to add a thread register to o32 (which produces a substantially
incompatible new ABI anyway).

Until that all works, what we had in mind is that we'd do NPTL over
o32 by defining a system call to return a per-thread ID which is or
can be converted into a per-thread data pointer.  We suspected that
NPTL's per-thread-data model allows the use of cunning macros or
library functions to make that look OK.

Ought we to go further and see exactly how that can be done?

--
Dominic

  reply	other threads:[~2004-08-20 13:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-04 22:29 anybody tried NPTL? Jun Sun
2004-08-05  1:08 ` Kumba
2004-08-05 17:14   ` Jun Sun
2004-08-06  2:03   ` Ralf Baechle
2004-08-19 14:17 ` Dominic Sweetman
2004-08-19 14:31   ` Alec Voropay
2004-08-19 14:31     ` Alec Voropay
2004-08-20  6:07     ` Dominic Sweetman
2004-08-20  6:07       ` Dominic Sweetman
2004-08-23 12:28     ` Ralf Baechle
2004-08-23 15:09       ` Alec Voropay
2004-08-23 15:09         ` Alec Voropay
2004-08-23 17:19         ` Ralf Baechle
2004-08-19 16:01   ` David Daney
2004-08-20  6:19     ` Dominic Sweetman
2004-08-19 22:16   ` Jun Sun
2004-08-20 13:46     ` Dominic Sweetman [this message]
2004-08-23 13:28       ` Daniel Jacobowitz
2004-08-23 17:12         ` Ralf Baechle
2004-08-23 17:44           ` Daniel Jacobowitz
2004-08-23 19:13             ` Ralf Baechle
2004-08-23 17:37         ` Jun Sun
2004-08-23 19:25           ` Ralf Baechle
2004-08-20 13:12   ` Thiemo Seufer
2004-08-20 16:52     ` Dominic Sweetman
2004-09-01  9:17   ` Richard Sandiford

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=16678.163.774841.111369@arsenal.mips.com \
    --to=dom@mips.com \
    --cc=jsun@mvista.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 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.