> Hello,
>
> > Here is my opinion: I want the kernel to provide a well-defined,
> > documented interface to modules. And I also want this interface
> > to be stable across different configurations, so that modules
> > keep working even when someone reconfigures their kernel.
>
> Are such interface changes worth the performance penalty they incur?
>
> I think it should be enough to add an mechanism preventing insertion
> of modules compiled for a different kernel (i.e., adding parameters
> like SMP-ness and physical memory size to the kernel version string
> stored in the module).
I beg to disagree. There is far too *much* information in the module
version system now. Instead of carrying around versions of everything,
and eventually the whole configuration file as well, a little discipline
would reduce the necessary information (and hence the opportunities for
mismatch) to two or three "interface versions" which would really mean
something.
[here he goes again] When VMS went from V5.x to V6.0 (a *major version
upgrade*), they only changed three of the perhaps dozen modules that make
up the VMS kernel. It is entirely possible that they didn't even
recompile the rest. There was no cascade of "kernel version 2.0.29
doesn't match module version 2.0.29". It all worked. That's what stable
interfaces do for you. They don't have to be elaborate or
performance-sapping; just *stable*.
I'm clearly missing something, but Linux module versioning has *never*
worked for me; it always works against me, so I turn it off. (Feel free
to tell me what I'm doing wrong.)
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu One more time: a (level-2) switch is a bridge. A "level-3 switch" is a router. Deal with it.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu