[2500] in SIPB_Linux_Development
Re: Kernel interface changes (was Re: cdrecord problems on
daemon@ATHENA.MIT.EDU (Derek Atkins)
Thu Feb 4 22:08:48 1999
To: alan@lxorguk.ukuu.org.uk (Alan Cox)
Cc: khim@sch57.msk.ru, arvinds@MIT.EDU, xiphmont@MIT.EDU,
linux-kernel@vger.rutgers.edu, linux-dev@MIT.EDU, jered@MIT.EDU,
nemo@MIT.EDU, cox@idecnet.com
From: Derek Atkins <warlord@MIT.EDU>
Date: 04 Feb 1999 22:08:03 -0500
In-Reply-To: alan@lxorguk.ukuu.org.uk's message of Fri, 5 Feb 1999 03:39:02 +0000 (GMT)
alan@lxorguk.ukuu.org.uk (Alan Cox) writes:
> Thats an extreme situation though. I think everyone is happy about it for
> binary compatibility at application levels. Juggling this kind of stuff to
> suit IBM's own problems isn't trivial. I think people have a right to expect
> 2.2.* to run binaries identically (well barring bug fixes meaning they now
> work right!) but at the module level its far from trivial.
Alan, I respectfully disagree (partly). I don't think it's at all
extreme to assume that people don't have source to everything on their
system. I also don't think it's extreme to expect commercial
operations to iterate through the release-engineering process at the
whim of the linux kernel developers.
I think we can both agree that it is certainly trivial to break module
compatibility. But I think it's also trivial, in _general_ to
maintain module compatibility in _most_ cases. I'm not saying that
certain changes, like the f00f or teardrop fixes, shouldn't have gone
in. On the contrary, I agree that those are reasonable changes to
have made, even in a stable release. But you have to admit that
breaking module compatibility for 'cache speed improvements' is _not_
reasonable, right? So the question here is: where is the line of what
is reasonable and what is not?
I'm not trying to define that line here. I'd like to trust the kernel
developers as a group to be reasonable and generally do the right
thing. I'm just trying to remind people of this issue, to point out
that there needs to be a conscious decision on everybody's part to
maintain module compatibility as much as possible. Really, all this
means is that we have to be careful what patches go into a stable
release, and if it is not absolutely necessary for the patch to go in,
it should go into the development tree instead.
Besides, Alan, it's not just IBM here -- they just happen to be the
first (transitive property through me). I know of at least a
half-dozen other hardware vendors who support linux through binary
kernel modules. I'm probably just the most vocal of the group ;)
FWIW, I don't work for IBM, and I never have. I created Linux-AFS as
a summer job, and I have maintained it ever since on my own time, as
an individual. So, for the last four long, hard years I've been
trying to perform a _FREE_ service to the Linux community, in
particular everyone in the world who uses IBM's software. Also, in
case you didn't know, neither IBM nor I made a single penny off of my
work.
The reason why I didn't write 'Arla' was that the RPC subsystem that
AFS uses, Rx, was not publically available in 1994. Also, it was
faster to start with the existing implementation, and we needed a
solution as soon as possible. I applaud the Arla team, but they had a
lot more to work from than I had.
> Alan
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
warlord@MIT.EDU PGP key available
