[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OCD programmers and backwards compatibility :-).

On Sun, Jan 28, 2007 at 02:43:19PM -0600, Les Mikesell wrote:
 > Dave Jones wrote:
 > >  > The same sort of attitude prevails in the kernel driver source code
 > >  > as well. I've had to patch and rebuild the truecrypt driver several
 > >  > times on new kernel releases, and not once has the change been anything
 > >  > substantive about the driver model. Once again, it is all ticky-tak
 > >  > junk like changing the name of a macro or routine because some moron
 > >  > who had the power didn't like the old name and didn't care how much
 > >  > work changing it foists off onto the rest of the world.
 > > 
 > > If the truecrypt driver had been submitted upstream, it would continue
 > > working across API changes.  Those 'morons' fix up all in-tree drivers
 > > when APIs change.  Complaining about a lack of stable ABI here is
 > > completely pointless btw. Upstream isn't interested, and there's
 > > less than zero chance Fedora will adopt a set in stone ABI deviating
 > > from upstream.
 > So does that mean that maintaining compatibility with anything outside 
 > that kernel developers' direct control is hopeless?  Should anyone who 
 > cares about that just switch to Solaris now?

If you care about a kernel symbol remaining constant forever,
then you're in for disappointment.  We do offer _some_ ABI guarantees
with RHEL releases, but it's a ton of work to do so (even just a subset).
Doing that for Fedora would require a lot of manpower which doesn't
exist today. It also requires sacrificing certain upstream changes entirely,
which makes for real pain when subsequent must-have fixes are implemented
on top.

This isn't about control, it's about long term maintainence.
If Linux had a stable in-kernel ABI, it would be a horrific mess
to work on, and certain problems would just be completely unfixable
in a clean manner.

If you want to see some of the horror show that proves this, take
a look at what happens to a RHEL release near end of life.
By that point, large parts of it have deviated from anything that
ever looked like upstream, because instead of taking upstream fixes,
we've had to bend-to-fit fixes to work around ABI constraints.

Thankfully, no RHEL release lasts forever.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]