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 -- _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info