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?
BTW, you can't just pick the largest possible size because your binary
only module needs to access spin locks that are exported by the kernel.
dma_spin_lock is exported so what happens if the module uses DMA? If
the module was compiled with SMP and SPINLOCK_DEBUG (default for 2.3
SMP) but the kernel was compiled with UP and DEBUG_SPINLOCKS == 0 then
your module will try to access dma_spin_lock+4 which does not exist in
the kernel - SPLAT!
Even worse are all the structures that have embedded spinlock_t
variables. To take just one example, struct net_device contains two
spinlock_t variables. Unless your binary only SMP network driver
module compiles with *exactly* the same expansion as the kernel, all
data in the second half of struct net_device will be accessed via
different offsets in the kernel and your code - even bigger SPLAT!
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.
-
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/