[OpenAFS] Hardware Grants from Sun

[Nicolas Williams]

On Sun, Feb 25, 2007 at 02:21:08AM -0500, Marcus Watts wrote:
> Going the other way from what Nico proposes, why not have a very
> general per-module way for modules to add resources per-process?
> 
> There's really only a few points where the "generic" environment
> needs to interact with the module:
> 	/1/ fork
> 		increment reference count to resource?
> 		copy resource?
> 		break attachment to resource?
> 			)) let the module choose here.
> 	/2/ exit
> 	/3/ module unload time
> 	/4/ 	ideally, also thread & exec logic...
> 		?? setsid ??
> if the module can associate data with a process, retrieve it on
> demand, & handle clone/fork issues - then it can implement pags
> just as they exist today.  It could also
> implement any other interesting structure of its choosing.
> This means any policy issues can be sorted out entirely by the module and
> do not need to be a concern of the enclosing os environment.
> Then other modules could experiment with different choices.
> There are probably already other kinds of data in the kernel,
> such as sysv ipc keys, that could be similarly described.
> 
> The generic mechanism here could be something like the userland
> "pthread_key_create" and "pthread_setspecific" -- or the pam_get_item
> & pam_set_item calls.  The least requirement is that the kernel
> provide hooks for modules to be invoked at the appropriate places.
> A more fully featured mechanism would provide a way to actually
> store per-process keys or data, perhaps to make this per-thread,
> and perhaps to interact with other interesting per-"session" kernel
> semantics.

Linux keyrings do much of this.  Including storing data in kernel-land.

One key requirement is to be able to detect IPC peer's PAGs, so that
daemons like gssd can do the right thing (alternatively we could use
per-user/session gssds and let the kgssapi kernel module upcall to the
correct one).

Nico
--