"Maciej W. Rozycki" wrote: > > On Thu, 5 Jul 2001, Florian Lohoff wrote: > > > > The R3k variant works fine for me. I was unable to thest the ll/sc one, > > > but the semantics should be unchanged, i.e. if it worked before, so it > > > will now. The patch should go into Linus' tree as well. > > > > How is this patch supposed to work in the means of how does it come around > > the -MAXERRNO stuff in scall32 ? > > It works as far as sysmips(MIPS_ATOMIC_SET) can. It does not add > anything new -- it merely fixes what is obviously broken (falling through > to MIPS_FIXADE from MIPS_ATOMIC_SET for non-ll/sc CPUs, what is being > currently done, is not the most brilliant idea, either). For better > handling I encourage you to use the _test_and_set patch I've sent here > recently. I'm using it exclusively for a few weeks now. > > I do not intend to maintain sysmips(MIPS_ATOMIC_SET) beyond fixing > obviously broken stuff. I'm voting only to keep it until we have a > replacement. It should go away in 2.5 for sure -- if you recall the > recent discussion, the conclusion was it's not really needed if we can > satisfy glibc differently. > That was the conclusion, but did not make to the CVS tree, probably due to Ralf's unwillingness to take a overhead for "flawed" CPUs. In my last patch for Vr41xx, I have a patch for this. Basically, I will send a SIGSYS if the return value is a small negative. This will practically satify all the need while keep the change minimum. The small modification to the semantic is not too bad at all if you consider the original syscall semantic is already badly broken. Jun
