On Thu, 2005-02-17 at 18:50 +0300, Evgeniy Polyakov wrote: > > > > +#if defined(CONFIG_CONNECTOR) && defined(CONFIG_FORK_CONNECTOR) > > I suspect CONFIG_FORK_CONNECTOR is enough.
The problem here is that if connector is compiled as a module and fork_connector as builtin there will be undefined reference to symbol like 'cn_already_initialized' or 'cn_netlink_send'. That's why the fork_connector() must be enable if CONFIG_CONNECTOR and CONFIG_FORK_CONNECTOR are selected as builtin and not as a module. I agree that it's not very elegant... > > + cn_netlink_send(msg, 1); > > "1" here means that this message will be delivered to any group > which has it's first bit set(1, 3, and so on) in given socket queue. > I suspect it is not what you want. > By design connector's users should send messages to the group it was > registered with > (which is obtained from idx field of the struct cb_id), in your case it > is CN_IDX_FORK, > and connector userspace consumers should bind to the same group (idx > value). > It is of course not requirement, but a fair path(hmm, I can add more > strict checks into connector). > By setting 0 as second parameter for cn_netlink_send() you will force > connector's core > to select proper group for you. Yes but cn_netlink_send() is looking for a callback with the same idx. As I don't use any callback, found == 0 and I have an error "Failed to find multicast netlink group for callback[0xfeed.0xbeef]". So the good call is: cn_netlink_send(msg, CN_IDX_FORK); Thanks for your help, Guillaume - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
