[OpenAFS] OpenAFS on Linux 2.5.x

[Derrick J Brashear]

On Wed, 16 Apr 2003, Jon Bendtsen wrote:

> > That's one example. Something needs to happen for PAGs also, and us
> > hooking the setgroups/getgroups calls is really the wrong answer.
>
> Why not just work with them if we want openafs included ?

No argument there, but they declared feature freeze, meaning in theory
that nothing gets to be done until after 2.6, because what we need would
be a "feature"

> > -have not added their own version for us to attempt to conform to.
>
> It doesnt work like that. It is Linus's kernel. He makes the stuff

It doesn't matter if it works like that. You'll note I provided options
for all the other cases. For completeness, they must also not be willing
to do this, because otherwise it means we're ignoring an "out" and we
suck.

> If you want something into the Linux kernel, you would have to work
> with the kernel people. You have to make changes to your code to fit
> it into the kernel. Anything else is just arrogant bullshit, you or
> anyone else has no (god/constitution/law/birth/... (or whatever you
> believe in) given) right to get your code included.

I sent a patch. It:

> However, it is my understanding that if you come with code that is:
> -
> generaly useable,

Yup.

> compiles cleanly without warnings

Yup.

> compiles on non x86

Yup.

> is licensed under GPL

Yup.

> doesnt break/change any other stuff in the kernel

Yup.

> TESTED

Yup.

> Then you USUALY will get it included. Especialy if you make it a
> compile time option.

Ok then. So, I played and lost. Do you have a suggestion that works?

> > You might argue we're about as unresponsive, but I can think of but one
> > example of that: David Howells' RPC proposals. I suggested as one
> > implementation the OpenAFS community had no business deciding what was
> > justified to add, and that the afs3-protocol list would be a better place
> > for such discussion.
>
> proposal? This sounds like David didnt show any code. The better code
> you show, the more likely you are to get it included.

I understand exactly what he wanted, and I could write the code in less
time than I'm taking to try to allow you to understand what's up with
Linux 2.5 and 2.6.

> > Unless I was dropped, no such discussion has happened. His proposals were
> > and probably still are worth implementing, even if our client is in no
> > danger of using them.
>
> Why not start with what is needed to get it working. And then after
> that make future changes for smart and optimised stuff. (notice how
> SMP got added, and how many kernel revisions it toke to make it good).

Because all of my free time ends being consumed by stupid political stuff
which I have no interest in doing, and in rewriting code that already
worked most often for the 50 variants of what purport to be the same
version of the Linux kernel.

> > "We haven't had time to deal with you" would be a fine explanation, but
> > I've seen nothing to indicate benign neglect rather than hostility as a
> > motive. If it is, then I will offer apologies.
>
> Please remember that it does take 2 to fight. I'm sure that there is

Sure. And you'll note I'm not fighting. I got frustrated and walked away.
If someone else wants or expects to deal, great. If any of the random
contacts I have pays off in a way that makes OpenAFS supportable in a way
useful to me on Linux 2.5, I will be willing to work on it. That's a real
possibility, but until I know what I'm going to have to work with, it's
premature to write code for it.

> ppss: it might be too late to have openafs included into the 2.6/3.0
> kernel, but that does NOT mean that we shouldnt try. At least the work
> is not waisted even if it isnt included in 2.5, as i am sure that some
> users would like to use openafs on the 2.6/3.0 and other future kernels.

we don't want openafs in the 2.6 kernel. we never asked for it, either.