Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
From: Balbir Singh <hidden>
Date: 2006-03-25 09:42:10
Also in:
lkml
On Fri, Mar 24, 2006 at 08:19:25PM -0500, jamal wrote:
On Fri, 2006-24-03 at 20:24 +0530, Balbir Singh wrote:quoted
Hmm... Would it be ok to send one message with the following format 1. TLV=TASKSTATS_TYPE_PID 2. TLV=TASKSTATS_TYPE_STATS 3. TLV=TASKSTATS_TYPE_TGID 4. TLV=TASKSTATS_TYPE_STATS It would still be one message, except that 3 and 4 would be optional. What do you think?No, that wont work since #2 and #4 are basically the same TLV. [Recall that "T" is used to index an array]. Your other alternative is to have #4 perhaps called TASKSTATS_TGID_STATS and #2 TASKSTATS_PID_STATS although that would smell a little. Dont be afraid to do the nest, it will be a little painful initially but i am sure once you figure it out you will appreciate it.
Thanks for the advice, I will dive into nesting. I could not find any in tree users who use nesting, so I have a few questions nla_nest_start() accepts two parameters an skb and an attribute type. Do I have to create a new attribute type like TASKSTATS_TYPE_AGGR to contain the nested attributes TASKSTATS_TYPE_AGGR TASKSTATS_TYPE_PID/TGID TASKSTATS_TYPE_STATS but this will lead to TASKSTATS_TYPE_AGGR TASKSTATS_TYPE_PID TASKSTATS_TYPE_STATS TASKSTATS_TYPE_AGGR TASKSTATS_TYPE_TGID TASKSTATS_TYPE_STATS being returned from taskstats_exit_pid(). The other option is to nest TASKSTATS_TYPE_PID/TGID TASKSTATS_TYPE_STATS but the problem with this approach is, nla_len contains the length of all attributes including the nested attribute. So it is hard to find the offset of TASKSTATS_TYPE_STATS in the buffer. Do I understand NLA nesting at all? May be I am missing something obvious. Thanks, Balbir