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
jamal wrote:
On Mon, 2006-06-03 at 12:00 -0500, Shailabh Nagar wrote:
My design was to have the listener get both responses (what I call
replies in the code) as well as events (data sent on exit of pid)
I think i may not be doing justice explaining this, so let me be more
On Mon, 2006-06-03 at 12:00 -0500, Shailabh Nagar wrote:
My design was to have the listener get both responses (what I call
replies in the code) as well as events (data sent on exit of pid)
I think i may not be doing justice explaining this, so let me be more
elaborate so we can be in sync.