Re: modules problems

Linus Torvalds (torvalds@cs.helsinki.fi)
Sat, 21 Sep 1996 09:52:26 +0300 (EET DST)


On Fri, 20 Sep 1996 warlord@mit.edu wrote:
>
> Why not just make all the exported kernel interfaces the same whether
> the kernel is single processor or SMP? You shouldn't need to have
> multiple modules for kernels with different configurations. The fact
> that modules need to be recompiled based upon the kernel configuration
> is a bug.

Well, right _now_ it might be possible to do that, but this is not really a
issue worth pursuing very much, because with finer-grained locking there will
be fundamental changes between the SMP and the non-SMP versions (there are
already _some_ changes, but they are currently not very large).

Note that although the source for SMP and non-SMP is the same, the header
files change a lot of definitions and inline functions so that a SMP
kernel looks very different from a UP kernel at a low level.

Now, you could consider _that_ a bug, but only if you don't care about
performance. The fact is that SMP needs to do things that simply aren't
needed at all on UP kernels, and I categorically refuse to slow down a UP
kernel only because of "in-kernel binary compatibility issues". That way lies
bloatware and non-optimal performance.

When SMP machines account for 99% of all Linux installations I might change
my mind (and UP would just be a SMP with one CPU), but right now it's the UP
kernel that is "more important" and trying to make SMP the default is just
not going to happen.

Just as one example of a (small) difference between SMP and UP kernels is
that a SMP kernel will use the "lock" prefix on atomic accesses (things like
"atomic_add()", "set_bit()" etc), while that isn't needed on UP. And
that's just the smallest of such changes.

Linus