[OpenAFS-devel] Fully Functional Client on Linux 2.6

[Jeffrey Hutzelman]

On Sunday, July 04, 2004 10:33:05 +0200 Tomas Olsson <tol@stacken.kth.se> 
wrote:

> Jeffrey Hutzelman <jhutz@cmu.edu> writes:
>
>>>> No, it's not OK to assume any chunk of memory containing 222
>>>> kernel-text addresses is the system call table.
>>
> True. On my first attempt with an opteron, I found the interrupt table
> instead.
>
>> vendors have started unexporting that, and the stock kernels may
>> follow suit very soon.  After all, it is the mission of the Linux
>> kernel developers to make life as hard as possible for anyone who
>> maintains code not in the kernel tree.
>>
> Please, take it easy. The syscall hack is a terrible thing, and we should
> stop doing it. Sure it's been done for ages and ages, that doesn't make it
> right. Sure it's our syscall, but unless we use it right or submit a
> palatable patch that gives us access in a reasonable way, we'll have to
> use other approaches. Most of the infrastructure we need is there, we
> just need to get it working. Then we can drop this whole awful hack.

I'm sorry, but that's wrong.

Yes, pags-in-groups is an evil thing, and I'd be happy to see it replaced 
by a standard facility that does what we need.

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 (icreat, iopen, iread, 
iwrite, iincdec, afscall, pioctl, setpag, settoken, gettoken, destroytoken, 
plus some things to manage cache manager parameters (the things that are 
currently pioctl's on the NULL path)).  The reason for that is that back in 
the 1980's when AFS was being written, existing OS's generally only had two 
syscalls that AFS could "steal" (stty and gtty).

Now on Linux we don't implement the inode ops, and we certainly could do 
most of the configuration and management stuff as /proc files if someone 
wanted to spend the time.  But pioctl, setpag, and token management still 
belong in the kernel and are still best accessed via a syscall interface.


In any case, please don't confuse _our_ syscall with the pags-in-groups 
hack.  We need access to the sys_call_table to do either, so 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.

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.




> 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 
because some bozo things all-the-world-is-Linux and that the whole universe 
should be made over in the image of Linux's architecture-of-the-week.

-- Jeff