Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: Joe deBlaquiere <jadb@redhat.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	"Kevin D. Kissell" <kevink@mips.com>,
	linux-mips@oss.sgi.com
Subject: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel
Date: Fri, 25 May 2001 15:02:46 -0700	[thread overview]
Message-ID: <3B0ED686.C1D85CE1@mvista.com> (raw)
In-Reply-To: 3B0D8F51.6000100@redhat.com


Alright, I rolled my sleeve and digged into IRIX 6.5, and guess what? 
sysmips() does NOT have MIPS_ATOMIC_SET (2001) on IRIX!  See the header below.

So apparently MIPS_ATOMIC_SET was invented for Linux only, probably just to
implement _test_and_set().  (It would be interesting to see how IRIX implement
_test_and_set() on MIPS I machines.  However, the machine I have access uses
ll/sc instructions).

Given the above understanding, I think we are free to add a new sysmips
subcall or even just change the current one if we want to.

Through the discussions, I hope we have achived the following concensus:

1. We need a correct syscall support to implement _test_and_set() on MIPS I
machine.  ll/sc emulation is not considered good enough to eliminate this need
due to performance concerns.
  
People who take this route understand that they may have to create extra user
land configurations.

2. Nobody seems to object the idea of ll/sc emulation per se, althought it is
not currently fully implemented based on my understanding.

People who prefer this route will enjoy the same ll/sc-enabled userland but
presumably take a performance hit on machines without ll/sc.

Anybody still have objections to the above conclusions?

-------------

Now back to the fix for syscall: the cvs tree is buggy as it is, as pointed
out by Florian.

I see several possibilities, which more or less the same as I brought up at
the beginning:

1) Florian's fix - introduce a new assembly routine to intercept
MIPS_ATOMIC_SET call so that correct return value is returned when there is no
error and error value is returned when there is an error.

1.a) A slight modification to 1) - we send a seg fault when there is access
error.  This solves two problems in 1).  

With 1), _test_and_set() will not be able to distinguish whether an error has
happened or a negative value is returned.  So in effect, error is mistakenly
ignored.  

The second benenfit is that with seg fault MIPS I implementation will have the
same behavior as MIPS II implementation which uses ll/sc.

2) Add a new subcall to sysmips, MIPS_NEW_ATOMIC_SET.  It takes three
arguments with the third one being the address to hold return value.  Again, I
think we should send seg fault on access errors.

The advantage of 2) is that we can still use the same sysmips() call without
introducing any new files.  The disadvantage is that people who use
MIPS_ATOMIC_SET directly is still subject to error, either in one form or
another.

To me, either 1.a) or 2) is fine with me, although I have a slight faovr over
2) (perhaps because I don't like assembly code and the extra "vertical"
calling layer introduced in 1.a)

--------------

So, please do us all a favor, can everybody who cares let us know :

1) can we agree on the concensus?

2) which fix do you like (naturally assuming you agree with the concensus)?

Let us work together and put a closure on this recurring matter!

Jun

  parent reply	other threads:[~2001-05-25 22:20 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-21 22:45 newest kernel George Gensure
2001-05-21 23:10 ` Pete Popov
2001-05-21 23:23   ` Jun Sun
2001-05-21 23:25     ` Pete Popov
2001-05-22 12:33     ` Florian Lohoff
2001-05-22 17:04       ` George Gensure
2001-05-22 17:04         ` George Gensure
2001-05-22 22:46       ` MIPS_ATOMIC_SET again (Re: " Jun Sun
2001-05-23  6:37         ` Joe deBlaquiere
2001-05-23 13:34           ` Maciej W. Rozycki
2001-05-23 17:48             ` Joe deBlaquiere
2001-05-23 18:20               ` Kevin D. Kissell
2001-05-23 18:20                 ` Kevin D. Kissell
2001-05-23 19:37                 ` Maciej W. Rozycki
2001-05-23 23:49                   ` Kevin D. Kissell
2001-05-23 23:49                     ` Kevin D. Kissell
2001-05-24  4:11                     ` Joe deBlaquiere
2001-05-24 10:56                       ` Maciej W. Rozycki
2001-05-24 10:44                     ` Maciej W. Rozycki
2001-05-24 15:15                       ` Kevin D. Kissell
2001-05-24 15:15                         ` Kevin D. Kissell
2001-05-24 16:21                         ` Maciej W. Rozycki
2001-05-24 22:46                           ` Joe deBlaquiere
2001-05-25 17:19                             ` Maciej W. Rozycki
2001-05-25 22:02                             ` Jun Sun [this message]
2001-05-25 23:56                               ` Surprise! (Re: " Jun Sun
2001-05-28 15:34                               ` Maciej W. Rozycki
2001-05-29 22:32                                 ` Jun Sun
2001-05-30  6:46                                   ` Kevin D. Kissell
2001-05-30  6:46                                     ` Kevin D. Kissell
2001-05-30 13:42                                   ` Maciej W. Rozycki
2001-05-30 17:39                                     ` Jun Sun
2001-05-31  8:37                                       ` Maciej W. Rozycki
2001-05-31 11:54                                 ` Ralf Baechle
2001-05-31 19:16                                   ` Jun Sun
2001-05-23 18:41               ` Jun Sun
2001-05-23 18:54                 ` Florian Lohoff
2001-05-23 18:55                   ` Florian Lohoff
2001-05-23 20:04                     ` Joe deBlaquiere
2001-05-24  9:32                       ` Maciej W. Rozycki
2001-05-26 13:14                         ` Florian Lohoff
2001-05-28 15:37                           ` Maciej W. Rozycki
2001-05-26 13:15                       ` Florian Lohoff
2001-05-28 15:43                         ` Maciej W. Rozycki
2001-05-28 16:25                           ` Kevin D. Kissell
2001-05-28 16:25                             ` Kevin D. Kissell
2001-05-28 17:10                             ` Maciej W. Rozycki
2001-05-29  6:57                               ` Geert Uytterhoeven
2001-05-29 10:45                                 ` Maciej W. Rozycki
2001-05-29 13:02                               ` Joe deBlaquiere
2001-05-29 15:45                                 ` Mike McDonald
2001-05-30  1:32                                   ` Mike McDonald
2001-05-30  7:09                                   ` Kevin D. Kissell
2001-05-30  7:09                                     ` Kevin D. Kissell
2001-05-30 14:48                                   ` J. Scott Kasten
2001-05-30 14:48                                     ` J. Scott Kasten
2001-05-29 22:37                               ` Jun Sun
2001-05-30 12:01                                 ` Maciej W. Rozycki
2001-05-30 17:54                                   ` Jun Sun
2001-05-31  7:39                                     ` Maciej W. Rozycki
2001-05-23 19:44                   ` Maciej W. Rozycki
2001-05-24  4:25                     ` Keith M Wesolowski
2001-05-23 21:06                   ` Jun Sun
2001-05-23 19:29               ` Maciej W. Rozycki
2001-05-23 17:10           ` Jun Sun
2001-05-23 13:18         ` Maciej W. Rozycki
2001-05-23 17:38           ` Jun Sun
2001-05-23 18:47             ` Maciej W. Rozycki
2001-05-23 20:58               ` Jun Sun
2001-05-23 13:45         ` wrt irc joshua
2001-05-23 15:19           ` porting from headers Keith M Wesolowski
2001-05-23 15:55           ` wrt irc nick
2001-05-23 15:57             ` Keith M Wesolowski
2001-05-23 16:03               ` nick

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=3B0ED686.C1D85CE1@mvista.com \
    --to=jsun@mvista.com \
    --cc=jadb@redhat.com \
    --cc=kevink@mips.com \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    /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