[OpenAFS-devel] Fully Functional Client on Linux 2.6

[Tomas Olsson]

Jeffrey Hutzelman <jhutz@cmu.edu> writes:

> However, the only about the afs_syscall that is an "awful hack" is
> that it's only one syscall instead of at least a dozen
>
Which means that we won't get it in the way it looks now. The pag & token
ops are (sort of, and broken, too) due for inclusion. I can't see why we
won't be able to get a few more in some day. If they are clean and it is
obvious enough to the lkml people that they are useful.

Besides, I'm not sure that patching the syscall table is all that beautiful
a practice.

> until there are better solutions to both (real PAG support in the kernel,
> /proc interfaces for cache manager configuration, and a
> filesystem-independent pioctl, at a minimum), we're going to have to keep
> doing something.
>
Sure.  I do my best. To get things working now, to get things in place for
the future.

> I expect I'd be a lot less bitter if the Linux folks hadn't decided to
> unexport the sys_call_table without providing us a mechanism to
> continue providing our syscall, _especially_ when they _did_ provide
> such a mechansim for the NFS server.
>
Some wild guesses, feel free to correct me:
lkml people used NFS. Nobody had any experience with AFS or the like. And
why include an ugly, multiplexing syscall that passes various pointers
around, when "nobody" uses it?

> > Collaboration is a good thing, war is bad. I don't care what this lkml guy
> > or that does, they are the way they are. We've got to accept it.
> 
> Sorry; I'm way past that point.  I've had about all I can take of being
> told that I should rearchitect my entire cross-platform software suite
> 
I'm not asking you to be happy about it. I'm asking you to be constructive,
or at least save some complaints for zgrams. And who knows, maybe the
design could be improved to the extent that is is worthwhile regardless of
the current linux situation.

/Tomas (rookie)