Messages in this thread | | | Date | Wed, 24 Sep 2008 23:36:17 +0400 | From | Alexey Dobriyan <> | Subject | Re: [kernel-abi] symbol versioning vs. out-of-tree modules. |
| |
On Wed, Sep 24, 2008 at 05:07:59PM +0200, Paweł Sikora wrote: > with out-of-tree kernel modules we (users and linux distributions) > have a problem - with every frequent kernel release we need > to rebuild them all due to vermagic and possible abi changes. > this leads to lot of useless work (bumping rpm specs releases, > preparing rpm packages and so on).
That's your price for using out-of-tree junk.
> naturally we could workaround the modprobe vermagic errors > but we currently can't detect the big-bang kernel abi changes.
And never will be able to.
> e.g., some kernel function changes its parameter list while > the exported function(symbol) name still staying unchanged. > finally we get a modprobe-big-bang.
*bang*
> in fact, we can't use a c++ symbol name mangling to avoid > such problems but kernel build system could use a linker script > to versioning symbols (like glibc/libgcc). during the abi change, > kernel developers could just bump the symbol version and > external modules could be refused during loading with > 'unresolved symbol' error which is imho much better solution > that an oops.
So kernel developers should waste time thinking if some change will result in some innumerable junk being broken, resulting in symbol version bump?
> is it acceptable and possible to introducing such solution?
No. Don't even bother. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |