On Wednesday, August 02, 2006 11:15:11 AM -0400 Derrick J Brashear
<[EMAIL PROTECTED]> wrote:
That would be fine, I suspect, since NFS v4 would probably also use it.
Kevin?
I believe NFS4 is going to store its keys in the keyring directly,
rather than using a PAG. Would that be possible for AFS?
Possibly, but not from day 1, which is how we are where we are now. It
requires a flag day, which it would be nice to sequester to a major
version release.
It seems this needs to be said again, so I'll say it.
It's not about storing keys. A PAG is not a place to store keys.
A PAG is a set of related processes.
We can't "store ... keys in the keyring directly, rather than using a PAG",
because we're not just "storing keys". Besides a set of keys, a PAG is
also associated with things like open connections to fileservers and cached
access rights. NFSv4 is going to have the same issues, at least if you
want the performance not to suck.
Also, please understand that the AFS cache manager is a complex beast that
is more-or-less portable and needs to run on a variety of platforms. It's
certainly possible to add features and alternate interfaces to take
advantage of the capabilities of each platform. However, it would be silly
to completely restructure the way credentials, connections, and the access
rights cache are managed in order to depend more strongly on Linux
keyrings, because we'd still have to do it the old way in order to support
all of the other platforms. That might be worthwhile if there were a
significant benefit to be gained, but I don't see one -- what we have now
works just fine, works the same on every platform, and doesn't require much
maintenance. It just needs a sane way to attach the same label to
processes that is attached to that other data, and that's what Chas's patch
is about.
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
