Messages in this thread |  | | | From | Keith Owens <> | | Subject | Re: Portable binary modules | | Date | Thu, 09 Dec 1999 14:48:51 +1100 |
| |
On 09 Dec 1999 01:13:19 +0100, Kjetil Torgrim Homme <kjetilho@ifi.uio.no> wrote: >[Horst von Brand] >> The locking primitives are inlined for performance, and radically >> different in both cases. The UP kernel has a definite advantage >> speedwise by _not_ handling SMP locks. Your idea is to compile >> everything as SMP then? > >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?
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/
|  |