Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Jan 2001 07:56:18 +1100
From:      Peter Jeremy <peter.jeremy@alcatel.com.au>
To:        "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc:        John Baldwin <jhb@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, Wilko Bulte <wkb@freebie.demon.nl>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@netplex.com.au>
Subject:   Re: cvs commit: src/sys/i386/conf GENERIC
Message-ID:  <20010116075618.F91029@gsmx07.alcatel.com.au>
In-Reply-To: <200101152012.f0FKCns56756@aslan.scsiguy.com>; from gibbs@scsiguy.com on Mon, Jan 15, 2001 at 01:12:49PM -0700
References:  <XFMail.010115114717.jhb@FreeBSD.org> <200101152012.f0FKCns56756@aslan.scsiguy.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-Jan-15 13:12:49 -0700, "Justin T. Gibbs" <gibbs@scsiguy.com> wrote:
>>So are you ready to write the code in trap() to handle an illegal instruction
>>fault in userland that decodes and executes all variants of cmpxchg?  The new
>>threading code in libc will be using atomic_cmpset() from userland, which is
>>going to be the main hurdle to get over.
>
>This is the wrong way to handle it.

I tend to agree.

>  Have atomic_cmpset() perform a fixup
>of the calling code on first entry and the result will be code as optimized
>as possible for the processor type the code is running on.

The other approach (at least for dynamically linked programs) is the
one Solaris uses:  linking against libX.so has an implied linkage
against machine/libX.so (if the latter exists).  This allows `generic'
functions to be replaced with ones that are optimised for a particular
processor.

>  If the user
>decides to write their own code that uses cmpxchg, they get what they
>deserve, but the primitives should not require a *fault* to work correctly.

The only way a user is going to get a cmpxchg in their code is if
they write one in assembler.  If a user is writing assembler code,
they should be expected to know what they are doing.

Peter


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010116075618.F91029>