On Tue, 20 Aug 2002, Maciej W. Rozycki wrote: > > Please accept the patch (from my previous mail). I'm using it now for > > two days, and I've got one mail telling me that it works for its sender. > > Ugh, this should be a separate set of functions selected at the run time. > It should be fairly trivial to rewrite it this way (best done with > processor-specific functions expanded from common templates for ease of > maintenance), but the size of the resulting interrupt masking window is > unacceptable. A more finegrained implementation is really desireable, > with an interrupt enable window every page or so, but your proposal should > be fair enough for the sake of usability once rewritten as I suggested. An additional thought that just came to my mind: it might be possible to avoid masking interrupts with a dummy ll/sc pair only checking if an interrupt happened within the critical code. It should be easy to validate since only a single mask of a processor would make use of the code. The real question is: "Do the affected cache operations corrupt any state or do they only work on wrong lines?" If the latter, the approach should work for all operations except from "Hit_Invalidate_D" that corrupts state by definition (but it isn't used by any R4k processor, so it may simply be replaced with a panic()). Unfortunately, the knowledge does no longer exist within IDT, but maybe someone else knows? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
