On Thu, 2005-02-24 at 07:41 +0100, Guillaume Thouvenin wrote: > On Wed, 2005-02-23 at 14:41 +0300, Evgeniy Polyakov wrote: > > > Please assume that <whatever secret application the connector stuff was > > > originally written for> will always be listening. > > > > > > > > What happened to the idea of sending an on/off message down the > > > > > netlink > > > > > socket? > > > ... > > > Arrange for the userspace daemon to send a message to the fork_connector > > > subsystem turning it on or off. So we can bypass all this code in the > > > common case where <secret application> is listening, but your daemon is > > > not. > > > > Ok, now I see(I'm not a fork connector author, so I did not receive them). > > That will require to add real fork connector with callback routing. > > Guillaume? > > Yes the connector's callback is a good solution. I will add a fork > enable/disable callback in drivers/connector/connector.c that will > switch a global variable when called from user space. It will be > something like: > > void cn_fork_callback(void) > { > if (cn_already_initialized) > cn_fork_enable = cn_fork_enable ? 0 : 1 ; > } > > With cn_fork_enable set to 0 by default. In the do_fork() I will replace > the statement "if (cn_already_initialized)" by "if (cn_fork_enable)"
Yes, it is right solution, but I do not think generic connector should have it. Create your own module that will "depend on CONNECTOR=y", which will register callback and export some function that will be called from do_fork() if FORK_CONNECTOR is defined and do nothing otherwise. I think you even need to create some simple protocol over connector, i.e.: void cn_fork_callback(void *data) { struct cn_msg *msg = (struct cn_msg *)data; if (msg->len != sizeof(cn_fork_enable)) return; memcpy(&cn_fork_enable, msg->data, sizeof(cn_fork_enable)); } And register cn_for_callback() with the connector. By default cn_fork_enable is zero and fork_connector() called from do_fork() will do nothing, otherwise cn_netlink_send(data, 0); Since something is registered with connector then "0" here will select appropriate group. Or you may still use CN_IDX_FORK. Userspace daemod, which is bound to the CN_IDX_FORK group will send cn_msg with the appropriate enable/disable message. Or you can even create more complex protocol, which will enable/disable various fork parameters to be logged... > > > Without a lock you can have two messages with the same sequence number. > > > Even if the daemon which you're planning on implementing can handle that, > > > we shouldn't allow it. > > > > Yes, they can have the same number, but does it cost atomic/lock overhead? > > Anyway, simple spin_lock() should be enough in do_fork() context. > > Guillaume? > > I will protect the incrementation by a spin_lock(&fork_cn_lock). > > Guillaume -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part