[...]
> > Yes, there really are two different names for
> > DEBUG_SPINLOCKS/SPINLOCK_DEBUG,
> > one for UP and one for SMP. So what size lock are you going to
> > allocate in your binary only SMP module?
> In the binary only module, you would do it the right way by telling the
> kernel to allocate a spinlock and pass back an opaque handle to it. You only
> allocate space for the spinlock handle, which is basically a void *.
You now have an access through a pointer via a function call (the module
can't know what it'll find at the other end of said pointer). Overhead that
makes a lot of sense for spinlock operations carefully optimized to be a
couple of inlined instructions in the common no-contention case, if they
are needed, or nothing at all elsewhere.
> [ snip ]
> > Bottom line - unless the kernel developers agree that no data
> > item will
> > ever change its size or meaning under any combination of UP/SMP, gcc
> > version and debugging options then you can forget about binary module
> > compatibility between UP and SMP.
> Or you start doing something that actually helps maintainability. You start
> using something called abstraction. Provide opaque interfaces to the objects
> rather than the raw structure. If you absolutely must have the penultimate
> in speed, I suppose you could even define it such that the first elements of
> the object is are function pointers for the various methods. Since many
> processors now have a zero branch delay, there wouldn't be a performance hit
> on those architechures.
Abstraction (source code wise) _is_ extensively used in the kernel. Nobody
really cares what a spinlock_t looks like, or if it was changed from one
release to the next. It is just that via function inlining, use of inline
asm() and plain dirty tricks the runtime cost for abstractions is pushed
down to almost zero, and this is one of the objectives behind Linux. That
level of performance (and the tuning flexibility the current setup affords)
is impossible to achieve (today at least) with binary only stuff.
> None of these are really new ideas.
Right. Interpreted languages (LISP style) are almost as old as compiled
ones (C style) are. You want abstraction, you go for LISP. You want raw
performance, you go for C. Linux is C style.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/