Re: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector

[Evgeniy Polyakov]

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

Attachment: signature.asc
Description: This is a digitally signed message part