Re: [PATCH 1/3] Process Notification / pnotify

[Matt Helsley <matthltc@us.ibm.com>]

On Mon, 2005-10-03 at 12:49 -0700, Paul Jackson wrote:
> Hmmm ... I notice with interest two notification patches posted in
> the last few days to lkml:
> 
>   Matthew Helsley's Process Events Connector (posted 28 Sep 2005)
>   Erik Jacobson's pnotify (posted 3 Oct 2005)
> 
> I suspect Matthew and Erik will both instantly hate me for asking, but
> does it make sense to integrate these two?
> 
> If I understand these two proposals correctly:
> 
>     Helsley adds hooks in fork, exec, id change, and exit, to pass
>     events to userspace.
> 
>     Jacobson adds hooks in fork, exec and exit, to pass events to
>     kernel routines and loadable modules.
> 
> Perhaps, just brainstorming here, it would make sense for Halsley to
> register with pnotify instead of adding his own hooks in parallel.
> This presumes that pnotify is accepted into the kernel, and that
> pnotify adds the id change hook that Helsley requires.

Paul,

	pnotify is extreme overkill for the process events connector. The
per-task subscriber lists, data, inheritance of those lists, tasklist
locking, and iteration over the lists are all overhead compared to the
process events connector patch.

	For the process events connector it makes more sense to have a global
list of subscribers interested all tasks. If there are M kernel modules
interested in getting events for all N tasks this would save space
proportional to M*N compared to pnotify. Of course this means the
elements of this list could not have per-task data.

	I think per-task data should be split out from pnotify and submitted as
a separate system used by pnotify. Maybe with a *_PER_TASK API similar
to *_PER_CPU.

Cheers,
	-Matt Helsley

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/