Messages in this thread |  | | | Subject | Re: kernel structures in 2.0.29->2.0.30 | | Date | Sat, 26 Apr 1997 06:39:17 EDT | | From | Maciej Stachowiak <> |
| |
Raul Miller <rdm@test.legislate.com> wrote:
>(1) It should be possible to ignore newer releases if, what you really >want is no change.
>(2) It should be possible to recompile the binary afs module, if what >transarc really wants is to support linux. [I disbelieve the >implication that the code base is so poor that recompilation + test >suite is a laborous process.]
Transarc has no interest whatsoever in supporting Linux. The port is unsupported work done by a volunteer, but cannot be released to arbitrary people in source form because of the terms of the license. A lot of people are dependent on using AFS for their daily work environment, and if they want to use it with Linux they have to depend on this volunteer port. Building and distributing a new release, and worse yet, having to maintain many releases at once, is a non-trivial task, and there are a very limited number of people with both the knowledge and the legal permission to do it. At least some consideration towards maintaining the binary interface for modules would make the maintainer's life a lot easier, and also the lives of people who depend on using AFS with Linux.
>(3) It should be possible for someone to hack together a wrapper for >the older module. This would translate between the new data >structures and the old at function invocation and return time. [Yes, >there's a performance penalty, yes it's work].
This is probably more work than recompiling the module, and for someone to do this he would almost certainly need acccess to the AFS source anyway.
>If you don't like option 2 or 3, why not try option 1?
People want the fixes available in the latest version, and it would unhelpful for the maintainer to just declare that they must use older versions to use AFS, especially since distributions are shipping with newer and newer kernels.
>I really don't see why you shouldn't be able to benefit from not >upgrading if not upgrading is what you really want to do. At worst >you have to buy another site license from Linus...
The goal isn't "not upgrading," it's being able to upgrade without breaking binary compatability for modules. In a stable series this deserves at least some consideration.
- Maciej Stachowiak
|  |