Hacking modversions

[Dave Jones]

On Tue, Mar 01, 2005 at 06:43:58PM +0000, Mike Hearn wrote:

 > It doesn't, and that's the end of the story. This is a "please do not
 > prevent self-compiled modules from loading unless there is a real need"
 > email, which I haven't seen brought up before (you have my apologies if it
 > was) and should not have much impact outside a bit more work for Dave
 > Jones I guess ;)

Congratulations. You win todays understatement of the day award.
You have no idea how maddening doing this is for RHEL.
If I had to do it for Fedora too, I think I'd be institutionalised by now.

To do this properly is an incredible amount of work. It's one of the reasons
that our enterprise kernels stick at one version for their lifetimes,
as to bend every change to fit the abi of your release kernel is just
so time-consuming (and sometimes its just not possible to fix some stuff
without breaking ABI).

 > Is this possible to do? It would require a careful analysis of the changes
 > being made to the kernel in online updates, but hopefully this already
 > happens anyway :) The actual build system modifications should not be too
 > tricky, I hope ...

For Fedora, I can't see this happening tbh.  For RHEL we get to be
really picky about which upstream cset's we pull in. Conservatism is
the name of the game there. Fedora users tend to want the latest and
greatest bits and pieces, and pulling in individual csets is just
going to be too much overhead given each point release upstream is
currently churning out around 4000 csets.  To maintain any kind of
illusion of the kabi you propose, you'd need to do this to throw out
the bits that break kabi so drastically.

It's counter-intuitive to the Fedora goal of staying as close to
upstream as possible, given that upstream doesn't give two hoots
about maintaining any kind of ABI compatibility between releases.

		Dave