[OpenAFS] Hardware Grants from Sun
Nicolas Williams
Nicolas.Williams@sun.com
Sun, 25 Feb 2007 13:21:36 -0600
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
--