On Sunday, July 04, 2004 10:33:05 +0200 Tomas Olsson <[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> 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 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
