On Mon, 2005-02-28 at 10:59 +0900, Kaigai Kohei wrote:
> Marcelo Tosatti wrote:
> > Yep, the netlink people should be able to help - they known what would be
> > required for not sending messages in case there is no listener registered.
> >
> > Maybe its already possible? I have never used netlink myself.
>
> If we notify the fork/exec/exit-events to user-space directly as you said,
> I don't think some hackings on netlink is necessary.
> For example, such packets is sent only when /proc/sys/.../process_grouping is
> set,
> and user-side daemon set this value, and unset when daemon will exit.
> It's not necessary to take too seriously.
I wrote a new fork connector patch with a callback to enable/disable
messages in case there is or isn't listener. I will post it this week.
Basically there is a global variable that is manipulated with a
connector callback so a user space daemon can manipulate the variable.
In the fork_connector() function you have:
static inline void fork_connector(pid_t parent, pid_t child)
{
static DEFINE_SPINLOCK(cn_fork_lock);
static __u32 seq; /* used to test if message is lost */
if (cn_fork_enable) {
[...]
cn_netlink_send(msg, CN_IDX_FORK);
}
}
and in the cn_fork module (drivers/connector/cn_fork.c) the callback is
defined as:
static void cn_fork_callback(void *data)
{
if (cn_already_initialized)
cn_fork_enable = cn_fork_enable ? 0 : 1;
}
Ok the protocol is maybe too "basic" but with this mechanism the user
space application that uses the fork connector can start and stop the
send of messages. This implementation needs somme improvements because
currently, if two application are using the fork connector one can
enable it and the other don't know if it is enable or not, but the idea
is here I think.
Regards,
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/
