Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel

[Martin Dalecki <dalecki@evision-ventures.com>]

Uz.ytkownik Alan Cox napisa?:
>>The main problem with mod-versions is the simple fact
>>that policy doesn't belong in to the kernel it belongs
>>in the user space. And mod-version is *just policy*.
> 
> 
> Nope. modversions are information about the ABI/API and objects referenced
> directly or indirectly from them.  The policy is entirely in modutils.
> Modutils has the power to say "well that looks kind of the same I'll bind
> that symbol name".
> 
> Kernel -> "Here is a helpful set of ABI compatibility hashes"
> Modutils -> "This symbol doesnt match, what do we want to do about it. Lets
> 	     fail". It could equally pick something looking similar.
> 
> 
>>It just DOES NOT BELONG in to the kernel-space.
> 
> 
> People who start using capital letters always seem to have emotional rather
> than logical reasons for their argument.

You are wrong.

ar r module.a module-symbol-versions-copyright-or-whatever
ar r vmlinuz.a symbol-versions-from-System.map

(Perhaps the ld variant with some section magic would be
  looking prettier and technically more correct.)

Shared libraries for example don't look up stuff like this inside
themselfs. (Unless you look at DLL stubs...)
It's the ld.so programm which maintains such data.
modutils don't do anything different from classical late binding.
The natural place for such maintainance work could be for example
the init process, which serves already pretty a similar role for
the kernel like ld.so does for user land applications. It would
provide a convenient point for possible synchronization...

Another analogy is the rpm dependency maintainance.
It's the rpm program - which does checking here and not
the actual application itself during the file-system install.