RE: Portable binary modules

Bret Indrelee (bindrele@sbs.com)
Thu, 9 Dec 1999 10:16:32 -0600

Keith Owens [mailto:kaos@ocs.com.au] wrote:
> 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?

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 *.

Then the kernel is allows to change the allocation attributes of a spinlock
whenever needed.

> 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!

Which is why you should be using opaque objects to reference the spinlocks.

[ 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.

None of these are really new ideas.

-Bret

-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity

Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------

-
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/