Hi Shailabh,My design was to have the listener get both responses (what I call replies in the code)
Apologies for taking a week to respond ..
On Mon, 2006-27-02 at 15:26 -0500, Shailabh Nagar wrote:
jamal wrote:
Yes, the current intent is to allow multiple listeners to receive the responses sent by the kernel.
Responses or events? There is a difference:
Response implies the program in user space requested (ex a GET) for that
information and is receiving such info.
Event implies the program in user space asked to be informed of changes
in the kernel. Example an exit would be considered an event. Events are received by virtue of registering to a multicast group.
[..]
Yes, I was trying to have an asymmetric model where the userspace sender of GETsSince this interface (taskstats) is currently designed for that possibility, having multiple listeners, one for
each "component" such as delay accounting, is the model we're using.
We expect each component to have a pair of userspace programs, one for sending commands and the other
to "listen" to all replies + data generated on task exits.
You need to have a sender of GETs essentially and a listener of events.
Those are two connections. The replies of a get from user1 will not be
sent to user2 as well - unless ... thats what you are trying to achieve;
the question is why?
Ok. Will this addition work for both unicast and multicast modes ?The listener is expected to register/deregister interest through
TASKSTATS_CMD_LISTEN and IGNORE.
It is not necessary if you follow the model i described.
How does this correlate to TASKSTATS_CMD_LISTEN/IGNORE?See above. Its mainly an optimization so that if no listener is present, there's no need to generate the data.
Also not necessary - There is a recent netlink addition to make sure
that events dont get sent if no listeners exist.
genetlink needs to be extended. For now assume such a thing exists.
Will this be necessary ? Isn't genl_rcv_msg() going to return a -EOPNOTSUPP
+
Good point. Should check for users sending it as a cmd and treat it as a noop.
More like return an -EINVAL
Yes.
I'm just using
this as a placeholder for data thats returned without being requested.
So it is unconditional?
Ok. will retain genetlink header.
Come to think of it, there's no real reason to have a genlmsghdr for returned data, is there ?
All messages should be consistent whether they are sent from user
or kernel.
Will do.Other than to copy the genlmsghdr that was sent so user can identify which command was sent
(and I'm doing that through the reply type, perhaps redundantly).
yes, that is a useful trick. Just make sure they are reflected
correctly.
Actually, the next iteration of the code will move to dynamically generated ID. But yes, will need to check for that.
Also if you can provide feedback whether the doc i sent was any use
and what wasnt clear etc.
Ok , so separate padding isn't needed to make the genlhdr, optionalhdr and TLV parts alignedThanks for the review.
Couple of questions about general netlink:
is it intended to remain a size that will always be aligned to the NLMSG_ALIGNTO so that (NLMSG_DATA(nlhdr) + GENL_HDRLEN) can always be used as a pointer to the genlmsghdr ?
I am not sure i followed.
The whole message (nlhdr, genlhdr, optionalhdr, TLVs) has to be in the end 32 bit aligned.
will do.Adding some macros like genlmsg_data(nlh) would be handy (currently I just define and use it locally).
Send a patch.
cheers,
jamal