lkml.org 
[lkml]   [1999]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Portable binary modules
From
Date
[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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.767 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site