> AFAIK, these are different approaches. In ELF symbol versioning, the
> developer assigns a version number, guaranteeing that versions are
> only changed if a binary incompatibility is introduced.
Ah, i see. I imagined that there was a catch, otherwise people like
Alan, Linus or Ted would surely have introduced it...
> In Linux module versioning, 'version' numbers are automatically
> generated from the signature of the symbol. Simple C++ style mangling
> is not sufficient, because you also want to encode the structure
> layout of the structures the function processes.
But wouldn't it be sufficient to know if the interface of a function
you are calling has changed? I know that won't help with data
structures, but wouldn't it be safer to disallow direct access of them
at all. Like only using methods to access data when using an OO
language. What would the mean in terms of speed and code?
> I believe a manual process would introduce inacceptable overhead, as
> those functions and data structures change more frequent than they do
> in, say, glibc (which follows standardized interfaces).
Yes. that makes it a problem. But if we would use only a set of
Kernel-API's between drivers and the rest of the kernel, it appears as
solveable. Of course one would have to define something like that...
Hmm. I guess that would mean a rather drastic change of kernel
internals, something i would rather not like to happen for the obvious
reason: if it ain't broken don't fix it.
Happy holidays to all of you!
Dominik Kubla