On Tuesday, July 18, 2006 12:36:00 PM -0400 Jim Rees <[EMAIL PROTECTED]> wrote:
I think if we have a setpag solution we should put it in the tree. We
will then be better off than we are now. We should encourage developers
to call setpag() rather than syscall(), and provide a library that
implements setpag(). If at some future time we are able to provide a
system call for setpag(), we can change the library, and applications
won't have to be relinked unless they were linked statically.
Well, there are a couple of problems with this.
First, setpag() is in libsys.a, which is an archive library; _everything_
that uses it is linked statically against that library. You seem to be
proposing that we create some new library which is used instead by every
application needing to call setpag. Stop for a moment and think about what
will be in this library; it's quite a lot (don't forget rmtsys). Before we
start making arbitrary changes to the set of libraries we provide, can we
_please_ come up with a coherent plan for this?
Second, the user/kernel interface (_not_ the application/library interface)
is one that we share with other software, including arla, KTH krb4, and
Heimdal. The AFSCALL_SETPAG and AFSCALL_PIOCTL interfaces _are_
well-defined, stable interfaces, and they need to be maintained.
The semantics of AFSCALL_SETPAG are that when you call it, you end up in a
new PAG. They are not that when you call it, you also have to do
additional platform-specific things, or risk ending up in a situation where
sometimes AFS uses the new PAG and sometimes the old. And, this is going
to get even worse when we finally stop storing PAG information in groups at
all, which we need to do in order to fix other problems arising from this,
such as the group-sorting issue mentioned earlier.
OpenAFS's user/kernel interface is supposed to be stable across versions;
you shouldn't have to update all of your applications in order for them to
work correctly with a new version of the kernel module. Chas is proposing
a change that not only requires applications to change once, but will
require them to change _again_ when we stop using groups to store PAG data.
That is unacceptable -- the LKML folks may not know a stable interface if
it came up and bit them, but I expect (demand) better from the OpenAFS
community.
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
