On Jun 17, 2010, at 4:05 AM, Bogdan Harjoc wrote:
On Thu, Jun 17, 2010 at 12:55 AM, Terry Lambert <
email@hidden> wrote:
On Jun 16, 2010, at 2:22 AM, Bogdan Harjoc wrote:
Generally speaking, the kernel, including any KEXTs you write, exists to
provide services for processes. Processes do not exist to provide
notifications or events to the kernel.
Makes sense. Since the KEXT already depends on a daemon to filter the
events, collecting the events using kqueue would require little extra
effort, if it were reliable. But as Wade suggested, I'll just submit
an enhancement request for process startup/exit notifications.
You should build a system that isn't dependent on this.
In the mean time, I'd like to ask is this approach is correct: call
proc_find(pid) which takes a reference to the proc_t, and then
proc_rele(pid) when the exit notification from kqueue comes. This
avoids the race, but will the process exit while I am holding a
reference to it ?
You should not hold a long-term reference on the process.
Your design will probably be better if you avoid state; keep a cache of recent activity hashed by PID, then periodically push the cache to your daemon. This lets you consolidate information so that your user/kernel communications are effective, but moves the responsibility of tracking PIDs out to userspace.
The daemon separately can track process lifecycles using kqueue, and associate cache entries from the kext with its own record of PID activity.