lkml.org 
[lkml]   [1997]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: useful LKM?
Martin von Loewis writes:
> > No. Don't user symbol versioning. It doesn't do what it promises to be.
> > And more importantly it doesn't make the modules independant from the
> > kernel version. Modules just can't be independant from the kernel. That
> > just like live is.
>
> Do you have a specific example (e.g. kernel versions, and module name)
> where module versioning did not fulfill your expectations? If so, did
> you try to analyse the problem?

I don't have a specific answer, but I know I've seen the message

Symbols for kernel 2.0.29 do not match symbols for 2.0.29

(or whatever that message is) way too many times. This always happens
after I do a kernel build, realize that I left out one option that
I meant to enable, and then recompile. The modules no longer work
even with this exact same kernel.

When module symbol versioning was introduced, I thought it was the
answer to module version between kernels, but I now believe I was
sadly mistaken. I no longer use module versioning, so I'm at least
guaranteed that a module will load in the same kernel version. If
that module accesses some member of a structure that was changed
because of the configuration, then the module could cause the kernel
to crash, but in practice, I've never seen that happen.

As someone pointed out earlier, a module may not need to get at the
internals of a structure even though it needs the structure pointer
to pass onto something else. With module versioning, the module
will no longer load because the structure has changed even though
nothing in the module cares about the structure change.

- Gordon

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