<<On Mon, 10 May 2004 19:02:26 -0400, Jeffrey Hutzelman <[EMAIL PROTECTED]> said:
But note that it's not exact. Your proposed afs_assign_process_label() doesn't actually provide a means to control what label is assigned.
Intentionally -- the AFS code should not preclude a model in which PAGs are actually addresses, which gives you a way to guarantee uniqueness in an SMP-friendly manner. Near as I can tell, except for the niggling little bits where AFS tries to fit uids and PAGs into the same name space, the kernel code just uses the PAG numbers as nonces, so it matters little if the numbers actually represent pointers.
That's correct.
When I was last looking at the code, about six months ago, I thought that the uid versus PAG confusion was fixable fairly easily: just lazily create a pseudo-PAG for every uid that touches AFS.
Yes, that would work.
If the system provides the right sort of hooks (FreeBSD does not, at the moment) you can even GC them easily.
I don't think that's a big deal. There's not currently any benefit to GC'ing PAG's, since they're just numbers in a namespace we don't expect ever to reuse. The tokens themselves will be GC'd once they are expired for some period of time, so the memory use is not an issue.
And, afs_get_label() expects to operate on a process, where what we currently want is a struct ucred or whatever passes for it. But then, that's platform-dependent code anyway, so it's not that big a deal.
That was a mistake on my part, since there are a number of places in the filesystem code where all you have is a credential and not a process anyway.
Ah. Yes, the main example of such a place is the NFS translator code, where we have the credential of the NFS client, but the current process (some NFS worker thread) is not relevant.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
