> Hello kernel hackers,
>
> I have given up on any CONFIG_MODVERSIONS work for a while, because it's
> too much work for too little payoff.
Makes sense to me *deep sigh*. CONFIG_MODVERSIONS used to be handy - but
these days it doesn't seem to help much. Though this look at modules
could be helpful to someone :)
> Roderich Schupp writes:
>
> > Isn't that was insmod already does? As far as I can tell insmod
> > insists on being a self-contained mini-linker (without employing
> > the help of ld or the like).
>
> Yes, it does. It has to bind names to values, and it has to do
> this directly into memory rather than into an output file. I don't
> think it would be useful to coerce gnu ld into this role. It is
> a similar function to ld.so, though.
No it would not help to coerce 'ld' into this role. The kernel may be
loaded at a different address every time - and that's where the binary has
to be relinked to handle. I actually like this system better than PIC
shared binaries actually for some work I like to do (VR). relocatable
binaries are faster than indirect ones for some things (especially on
systems with too few registers such as the x86 line).
I was describing somewhat internally (without going into details) how a
module was loaded using insmod... Thought it might help to describe?
Signing off... G'day, eh? :)
- Teunis