Subject: Re: p_flag in struct proc: int -> uint64_t
To: Elad Efrat <elad@NetBSD.org>
From: Jason Thorpe <thorpej@shagadelic.org>
List: tech-kern
Date: 10/05/2006 14:36:04
On Oct 5, 2006, at 1:40 AM, Elad Efrat wrote:

> Jason Thorpe wrote:
>
>> Ok, here is a generalized (and currently untested) "specificdata"
>> implementation, based on Yamamoto-san's.  proc, lwp, and session
>> specific-data could be built on top of this, a'la (note this is
>> incomplete):
>> [...]
>
> This looks very useful (and a lot like fileassoc(9), actually :).

In fact, you could probably replace the internals of fileassoc(9) with  
this framework (and maintain the current fileassoc(9) API, probably).   
This stuff is modeled after pthread_{get,set}specific() (for thread- 
specific data), but by adding the notion of a "domain", then anything  
can really adopt it.

> IIUC, can we use this to extend various objects in the kernel, with
> a single change to their structure? I have some thoughts about using
> it for extending a kauth_cred_t...

Right.  For example, you could use this to, for example, associate a  
Kerberos credential with a kauth_cred_t.

-- thorpej