> I've heard that SMP kernels are slightly slower
>than UP, but as far as I am aware that is the only
>drawback nowadays. Maybe we should think about
>dropping the UP support, and running on UP
>machines as single processor SMP. The odd percent
>slowdown is lost as a couple of weeks of Moores
>Law and maybe we could reduce the complexity of
>the kernel on the back of it?
Let's say 80% of the computers runing Linux don't have the 'x' nice
feature (with x=SMP, 4gig support, MTTR support, whatever).
1) Are we willing to make 80% of Linux users angry because of this 'x'
they just can't offer ?
2) And do we want to make 20% of Linux users angry because this 'x'
they've paid for is not working for Linux ?
I think the current answer of the Linux community is 1) NO and 2) NO
The use of preprocessor macros in the Linux source is a good solution
because you can always have the fastest possible kernel for your
hardware but makes totally impossible to build modules that are binary
compatible between SMP and UP machines, Bigmem and non bigmen computers
...
>I would be keen for a single size fits all, the
>hardware vendors that like binary modules would also
>like binary compatibility across a release.
Linus is against binary modules for both theological (open source / free
software, brothers) and technical reasons (it far more easy to improve
the kernel if you don't have to stick to binary compatibility).
End of story unless you find a way to make a binary module API that is
extensible, fast and simple....
In the other hand hardware vendors will not support Linux if they have
to write one version of their driver for each minor release of Linux and
this is more and more difficult for distribution makers to have as many
compiled kernels as we have possible technologies combinaisons (regular,
SMP, bigmen, SMP+bigmen, ...).
So why not adding a new target into the official kernel (make
autodetect) that detects the general architecture (you have SMP and a
P-III with 4gig of ram), builds the kernel and install it ? Each
distribution could do this just after the setup.
Why not change the insmod command to compile automaticaly the modules
before inserting them and distribute them only in source format ?
I don't know if it would be possible to insert a module into the kernel
after the compilation if you didn't register the module before (with the
M option in 'make config') but it might be a good solution if we could.
After all, compiling 20k modules is not so long on most computers.
>Wild idea : Remember the old Microsoft idea of fat
>applications (back when they did more than just
>Intel) - maybe we could coax gcc to cross-compile
>applications for i32/alpha/sparc etc to some heavily
>extended elf format and then we could have single
>releases of applications. Of course it would suck
>diskspace like theres no tomorrow, but It'd help
>the non-intel crowd that don't like compiling things.
>(This method works over NFS, unlike including <x>
>RPM's for each architecture in a meta-rpm and only
>extracting a subset)
The RPM file could have instructions to compile and install the modules
too
>Tim Towers
-
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/