[OpenAFS] OpenAFS on Linux 2.5.x

[Jon Bendtsen]

Derrick J Brashear wrote:
> On Tue, 15 Apr 2003, Derek Atkins wrote:
> 
> 
>>You mean in terms of inserting ourselves into the sys_call_table?  Or
>>are you referring to something else?
> 
> 
> 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 ?


>>I don't think all the kernel people are treating "us" that way --
>>although there are certainly a few pundits who do.
> 
> 
> The ones who might add code to the kernel:

Are there more than Linus himself? True others have their own trees,
but how many actualy uses them? I had the impression that either
people used the one that came with the distribution, or people uses
stock linus tree. (true, 2.4 is not Linus but Marcello? but thats
another story since Linus gave him/her that tree).



> -have not added ours
> -have not offered hint of what they might add

I'm sure that there have been plenty of postings of what they like
and dont like about code being included in the kernel. I can imagien
stuff like:

- 
small incremental changes to the kernel, so they can see
	and understand what it is they include
- 
must compile without warnings
- 
must compile on non x86 hardware
- 
must be licensed under GPL

I certainly remember alot of discussions back in 2.1? where the ISDN
people came to Linus with a ++BIG patch that they wanted included.
And there was the PCMCIA stuff too.


> -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
he uses, and likewise with the other kernel devellopers. Just see
the fuss about PCMCIA where Linus wrote his own driver, even though
there was another driver, there were just ... some disagreement and
dispute.
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.

However, it is my understanding that if you come with code that is:
- 
generaly useable,
- 
compiles cleanly without warnings
- 
compiles on non x86
- 
is licensed under GPL
- 
doesnt break/change any other stuff in the kernel
- 
TESTED

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


> 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.


> 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).


> Everything else is handled, or at least we admit we don't understand how
> to deal yet, as quickly as we can. I'm still waiting to figure out what's
> going to happen with Linux 2.(x>=5) 6+ months after I broached it, and far
> longer after other people did.

New drivers will get added. Work will continue on the scheduler, LVM,
reiserfs, acpi, ... and hopefully openafs :)


> "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
a misunderstanding somewhere. If someone came with a fresh perspective
and showed some good working code that compiles cleanly without warnings
even on non x86 hardware, and is throughly tested, and feeds Linus with
small incremental patches, then i believe that there is a chance to get
it included. But if "we" sit arround and bitch and do nothing... then
NOTHING is what will happen.


> And again, incidentally, I'm wearing nobody's hat but my own when I say
> this; I put in (my own) time as a Linux developer, and as such I do
> (despite perhaps not being entitled to) have an opinion.

Of course you are entitled to have an opinion, but you are not entitled
to have your code included into the Linus kernel just because you want it.




JonB

ps: (std.disclaimer) i might not remember everything correctly and this
post is just my impression and opinions, DONT take it as fact!

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.