Messages in this thread | | | Subject | Re: Portable binary modules | From | Kjetil Torgrim Homme <> | Date | 09 Dec 1999 06:41:31 +0100 |
| |
[Keith Owens]
> >Just the module. If inserted into a UP kernel, grabbing the lock > >would never fail. Is it really impossible to do this? (Please > >educate me.) The only cost I see is the memory for the locks which > >the UP kernel needs to allocate, even though it will never use > >them. > > Compile options, kernel 2.3.31 sizeof(spinlock_t) > UP, gcc >= 2.8.x, DEBUG_SPINLOCKS < 1 0 > UP, gcc < 2.8.x, DEBUG_SPINLOCKS < 1 4 > UP, any gcc, DEBUG_SPINLOCKS == 1 4 > UP, any gcc, DEBUG_SPINLOCKS >= 2 12 > SMP, any gcc, SPINLOCK_DEBUG undefined 4 > SMP, any gcc, SPINLOCK_DEBUG defined 8 > > 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.)
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.
> 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.
Kjetil T.
- 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/
| |