From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: atul srivastava <atulsrivastava9@rediffmail.com>,
linux-mips@linux-mips.org
Subject: Re: a quick question regarding CONFIG_MIPS_UNCACHED..
Date: Fri, 29 Nov 2002 13:42:30 +0100 [thread overview]
Message-ID: <20021129134230.A11704@linux-mips.org> (raw)
In-Reply-To: <Pine.GSO.3.96.1021128172026.8D-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Nov 29, 2002 at 12:56:10PM +0100
On Fri, Nov 29, 2002 at 12:56:10PM +0100, Maciej W. Rozycki wrote:
> > We've talked about this before - the specification of the ll/sc
> > instructions says they only work ok on cached memory. In the real world
> > they seem to work also in uncached memory but I'd not bet the farm on
> > that, too many implementations out there, too many chances for subtle
> > bugs.
>
> Indeed -- CONFIG_MIPS_UNCACHED should either be removed or imply
> CONFIG_CPU_HAS_LLSC=n. I suppose there is some interest in the option, so
> the latter is preferable. That would imply moving the option into the CPU
> configuration section as now it's set very late, long after
> CONFIG_CPU_HAS_LLSC is set. Or it could be set up the other way, i.e. the
> option would only become available if CONFIG_CPU_HAS_LLSC had been set to
> n. There would be no need to move it then.
>
> What do you think?
I had the same thought. So far there are the following groups of people
using this option:
- Hardware people using it so the the entire program is becoming visible
externally.
Becoming obsoleted by more advanced, less intrusive hardware debugging
methods.
- Software people kluding around bugs in their software.
Don't expect me to support this. Note with a line of code.
- For testing if the cache code is actually working.
Will only be useful to show big fat bugs. For the more subtle bugs
there is no way at all around understanding the entire cache managment
thing including all subtilities. Actually a good reason to not support
this option either.
It's been my observation that hardly any user is aware of these consquences
nor is the Linux code making a good attempt at complying with all the
additional restrictions of running uncached. So in my oppinion
CONFIG_MIPS_UNCACHED should go. But I don't feel very strong about it so
I'm going to wait for a few days so others have a chance to raise their
voice.
Ralf
next prev parent reply other threads:[~2002-11-29 12:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-27 9:11 a quick question regarding CONFIG_MIPS_UNCACHED atul srivastava
2002-11-28 15:51 ` Maciej W. Rozycki
2002-11-28 16:15 ` Ralf Baechle
2002-11-29 11:56 ` Maciej W. Rozycki
2002-11-29 12:42 ` Ralf Baechle [this message]
2002-11-29 13:03 ` Maciej W. Rozycki
2002-11-29 13:42 ` Ralf Baechle
2002-11-29 14:23 ` Maciej W. Rozycki
2002-11-29 13:49 ` Carsten Langgaard
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=20021129134230.A11704@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=atulsrivastava9@rediffmail.com \
--cc=linux-mips@linux-mips.org \
--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