[...]
> > 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?
> (Note, I didn't want this for a "binary only" module. I just want to
> be able to compile a module exactly _once_, not once for each
> workstation I administer.)
Then run the same kernel on each. It's what you'll be doing anyway, I'd
suspect.
> DEBUG_SPINLOCKS is a red herring. You just don't use DEBUG_SPINLOCKS
> on production machines, and on a one-off test compile it's fine to
> compile the kernel and the module in lock step. Anyway, I don't care
> as long as sizeof(spinlock_t) is the same in SMP and UP, everything
> else being equal. The difference in GCC version is exactly the
> optimization which I want to remove. Especially if it removes two
> variables in one swoop (gcc version and SMP), but I suspect there is
> more to the dependence on gcc version.
Great. Start removing optimizations for binary module compatibility's sake.
> > 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.
> I think some kernel developers sometimes go overboard in their
> optimization :-) Saving four bytes in each spinlock just isn't worth
> the hassle, IMO.
It's close to no hassle in this particular case. And probably similar in
other optimizations you will end up deleting afterwards. And then you'll go
after those were they went to the hassle _because_ it makes a significant
difference in performance.
No, thanks.
-- 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/