On Fri, 29 Nov 2002, Ralf Baechle wrote:
> 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.
I completely agree with your points and I'm not fond of this option,
either. I had a need to run uncached to debug a problem once and even
then it was on the R3k, so I had to set up things differently from what
that option does anyway. I can't recall the details of the problem, but
coding hooks for an uncached setup took me maybe half an hour, so I don't
think that is a problem for anyone who really needs it.
BTW, how do you know that ll/sc happens to work for uncached operation on
some processors? Maybe it simply fails, but the result is subtle enough
not to be observed easily. A failure may be masked by other factors, e.g.
for the UP operation, there is normally no way for two parallel requests
for a spinlock to happen and an exception resets the LLbit regardless of
the caching attribute of the area involved.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|