Messages in this thread | | | Subject | Re: [Lse-tech] Re: A common layer for Accounting packages | From | jamal <> | Date | 28 Feb 2005 08:40:10 -0500 |
| |
netlink broadcast or a wrapper around it. Why even bother doing the check with netlink_has_listeners()?
cheers, jamal
On Mon, 2005-02-28 at 08:20, Thomas Graf wrote: > > Havent seen the beginnings of this thread. But whatever you are trying > > to do seems to suggest some complexity that you are trying to > > workaround. What was wrong with just going ahead and just always > > invoking your netlink_send()? > > I guess parts of the wheel are broken and need to be reinvented ;-> > > > If there are nobody in user space (or kernel) listening, it wont go anywhere. > > Additional you may want to extend netlink a bit to check whether > there is a listener before creating the messages. The method to do so > depends on whether you use netlink_send() or netlink_brodacast(). The > latter is more flexiable because you can add more groups later on > and the userspace applications can decicde which ones they want to > listen to. Both methods handle dying clients perfectly fine, the > association to the netlink socket gets destroyed as soon as the socket > is closed. Therefore you can simply check mc_list of the netlink > protocol you use to see if there are any listeners registered: > > static inline int netlink_has_listeners(struct sock *sk) > { > int ret; > > read_lock(&nl_table_lock); > ret = list_empty(&nl_table[sk->sk_protocol].mc_list) > read_unlock(&nl_table_lock); > > return !ret; > } > > This is simplified and ignores the actual group assignments, i.e. you > might want to extend it to have it check if there are listeners for > a certain group. >
- 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/
| |