lkml.org 
[lkml]   [1997]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: kernel structures in 2.0.29->2.0.30
Date
From



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



\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2011 Jasper Spaans