[OpenAFS-devel] Re: openafs / opendfs collaboration

[Kyle Moffett]

On Jan 25, 2005, at 19:11, Jeffrey Hutzelman wrote:
>> My main point is, why do we need PAGs?  You don't just have to store
>> credentials in a keyring, you can store a (single) shared connection.
>
> Things a PAG is not:
> - a set of credentials
> - a place to store things
> - a 32-bit number
> - a pair of funny groups
>
> A PAG is a set of processes.  In fact, it's very nearly identical to
> what you called a "key session".  We do in fact need PAG's, or
> something equivalent.  And, we need a way to "name" PAG's, so that we
> can label other data structures as to which PAG they belong to.
>
> However, we do need to be able to label open connections and cached 
> access rights as to what PAG they belong to.  Note that we're not 
> talking about one open connection per PAG; we're talking about one 
> open connection per PAG per fileserver.  And we're not talking about a 
> cached set of groups or SID's or something; we're talking about cached 
> data on individual files indicating what operations we are allowed to 
> do on that file.  So, it's not a couple of items per PAG; it could be 
> in the tens of thousands.
>
> We already have data structures and code which manages this 
> information. That code is cross-platform, and we'd like to keep it 
> that way. Introducing a pervasive platform-dependent difference in 
> behaviour does not improve the maintainability of our code.

Ok, so the requirements are:
	1)	Shared between multiple processes with sane inheritance
	2)	Store a pointer to arbitrary arch-independent data structures
	3)	A unique globally-useable ID to locate a particular combination
		of credentials, connection data, caches, etc.

As I see it, the keyring system can very simply be dropped in place of
the existing setgroups hooks.  You can implement your own key_type
data structure (struct key_type afs_pag_key_type;) that contains a
pointer to an arch-independent AFS structure containing connections,
caches, etc.  Then instead of a "PAG" id, you would use a "key" id,
except you would need to check if the key is of afs_pag_key_type first.
Creating and using the key is trivial with the struct key_type hooks,
and it manages the inheritance automatically for you.  That way you
could manage all your own internal interfaces, caches, etc, and only
rely on the keyring system to keep track of processes for you.  The
one thing the keyring system _doesn't_ provide is a list of processes
that have a certain keyring, primarily because that slows the system
down considerably and chews up a lot more RAM. :-D

>> I didn't design or write it. :-P  I helped out David Howells by
>> commenting on his code and design, but I did not code a single line 
>> for
>> it.
> Hm; that wasn't the impression I got during our previous discussion,
> around the time some of the design work was happening.  But OK.  I
> suppose I should say for the benefit of others reading that I wasn't
> trying to devalue your comment, just giving credit where I thought it
> was due.

Well, I tried my hand at some initial patches, but David Howells had
more code written better, and I didn't have sufficient time to work on
it, so he wrote all the code.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------