[OpenAFS-devel] Re: [OpenAFS] 2.6 kernel support anytime soon? Workarounds?

[Pete Zaitcev]

On Mon, 10 May 2004 14:31:02 -0400
"chas williams (contractor)" <chas@cmf.nrl.navy.mil> wrote:

> In message <Pine.GSO.4.58-035.0405101332280.8116@johnstown.andrew.cmu.edu>,Derr
> ick J Brashear writes:

> >i'm sort of curious what spirit having a system call that no one's
> >willing to provide an interface to register kernel code to handle it is.
> 
> i suspect that if you put the syscall bits from openafs into the linux
> kernel and did it the 'right' way meaning that the syscall is not just
> a catchall, it would be accepted.   the kernel developers dont want to
> see:
> 
> 	afs_syscall(u1, u2, u3, u4) {
> 		(*call_afs_syscall)(u1, u2, u3, u4);
> 	}
> 
> i believe someone had this discussion with them at one point.

This is a valid point for the post-137 PAG work, such as one Howells does,
but is not relevant to the current use of the 137, which is what is at
the table today.

You seem to be leaning towards the migration to the new PAG API in the 2.6
frame. I do not see how this can be pulled off. Howells apparently gave
up on that, and without him someone else has to do the strong advocacy.
By strong I mean showing code and not just yapping on mailing lists.

Also this does not approach the interface between the "new PAG" or
"universal PAG" and the actual AFS client. In case of Howells' client
it's an non-issue, because it is GPLed and integrated. If you go for
an external module, you have to confront that interface.

In a word, more difficult than just splitting syscalls.

-- Pete