Florian Lohoff wrote: > On Wed, May 23, 2001 at 08:54:12PM +0200, Florian Lohoff wrote: > >> My favourit would be to let the glibc on runtime decide whether >> to use sysmips or ll/sc in the atomic test_and_set stuff. This would >> lead to an common atom op in the userspace which is fast on ll/sc >> cpus and gives much lesser performance penaltys in the sysmips case >> than emulating ll/sc. > > > But again - I tried to run this discussion again and again - As long > as there is no code to use there is no point in taking a discussion. > I needed a working sysmips for debian as we compile the glibc with > sysmips (performance penalty but for now works everywhere) thus > i fixed the sysmips. > I have to agree with the pragmatism first, philosophy second approach. If it is beautiful but doesn't work it dosn't help anyone. The thing I don't understand is how glibc is going to cleanly decide at runtime which code to use. It's relatively easy to do something like that in the kernel, but I can't come up with an elegant solution to make such a choice at runtime in glibc. Assuming that we're moving forward (as Kevin points out) the percentage of systems without ll/sc is going down. While these systems don't have much CPU power to spare, we should make the baseline implementation have ll/sc emulation. If somebody wants to make a MIPS I optimized glibc, then that's fine, but allowing the 'standard' MIPSII glibc to work on all systems simplifies life ( mine at least ;) ). -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839
