> 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.[1]
Nope. You'd need to set up all the locks, even though they aren't
used. This isn't done at present (for bloat and performance reasons).
> > > In many cases binary modules could easily be built as SMP compatible
> > > without any real performance hit on the system. If there is a
> > > performance hit, the developer can build both SMP and UP versions of
> > > the modules.
> > And for large memory, and not. And for i386, i486, i586 and
> > i686. And so on. Get real.
> It is a pain to maintain hundreds of machines which vary in subtle
> ways. If I could compile a module _once_ and rdist it to all the
> workstations, it would make life a lot easier.
You can do that today too, as long as they all use essentially the same
kernel. But then you can't tune your kernel to the specific machine you
have. Can't have it both ways.
> I don't see why it is so evil to reduce the variables when compiling a
> module. Combinatorial growth and all that.
The real variable here is kernel version, and interfases inside the kernel
_do_ change dramatically during development phases, i.e., inside the
year. Sometimes they change during a stable series too.
> [1] It looks like the memory _is_ allocated if you compile with GCC < 2.8...
Which will probably be a bad idea with 2.4.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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/