On Fri, 2006-10-03 at 22:09 +0530, Balbir Singh wrote:
On Fri, Mar 10, 2006 at 09:53:53AM -0500, jamal wrote:
On kernel-user (in the case of response to #a or async notifiation as
in #b) you really dont need to specify the TG/PID since they appear in
the STATS etc.
I see your point
On Thu, 2006-09-03 at 20:07 +0530, Balbir Singh wrote:
Please find the latest version of the patch for review. The genetlink
code has been updated as per your review comments. The changelog is provided
below
1. Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE
2. Provide generic
On Fri, 2006-10-03 at 09:53 -0500, jamal wrote:
a) shipping of the taskstats from kernel to user-space asynchronously to
all listeners on multicast channel/group TASKSTATS_LISTEN_GRP
at the point when some process exits.
b) responding to queries issued by the user to the kernel for
On Fri, Mar 10, 2006 at 09:53:53AM -0500, jamal wrote:
On Thu, 2006-09-03 at 20:07 +0530, Balbir Singh wrote:
Please let us know if we missed something out.
Design still shaky IMO - now that i think i may understand what your end
goal is.
Using the principles i described in earlier email,
Thanks for the clarification of the usage model. While our needs are
certainly much less complex,
it is useful to know the range of options.
There are no hard rules on what you need to be multicasting and as an
example you could send periodic(aka time based) samples from the kernel
on a
Balbir Singh wrote:
snip
Hello, Jamal,
Please find the latest version of the patch for review. The genetlink
code has been updated as per your review comments. The changelog is provided
below
1. Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE
2. Provide generic functions called
