Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262065AbVCVHII (ORCPT ); Tue, 22 Mar 2005 02:08:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262060AbVCVHII (ORCPT ); Tue, 22 Mar 2005 02:08:08 -0500 Received: from ecfrec.frec.bull.fr ([129.183.4.8]:24263 "EHLO ecfrec.frec.bull.fr") by vger.kernel.org with ESMTP id S262263AbVCVHHm (ORCPT ); Tue, 22 Mar 2005 02:07:42 -0500 Subject: Re: [patch 1/2] fork_connector: add a fork connector From: Guillaume Thouvenin To: Ram Cc: Jesse Barnes , Evgeniy Polyakov , Andrew Morton , lkml , Jay Lan , Erich Focht , Gerrit Huizenga , elsa-devel In-Reply-To: <1111438349.5860.27.camel@localhost> References: <1111050243.306.107.camel@frecb000711.frec.bull.fr> <200503170856.57893.jbarnes@engr.sgi.com> <20050318003857.4600af78@zanzibar.2ka.mipt.ru> <200503171405.55095.jbarnes@engr.sgi.com> <1111409303.8329.16.camel@frecb000711.frec.bull.fr> <1111438349.5860.27.camel@localhost> Date: Tue, 22 Mar 2005 08:07:32 +0100 Message-Id: <1111475252.8465.23.camel@frecb000711.frec.bull.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-MIMETrack: Itemize by SMTP Server on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 22/03/2005 08:17:09, Serialize by Router on ECN002/FR/BULL(Release 5.0.12 |February 13, 2003) at 22/03/2005 08:17:09, Serialize complete at 22/03/2005 08:17:09 Content-Transfer-Encoding: 7bit Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1216 Lines: 37 On Mon, 2005-03-21 at 12:52 -0800, Ram wrote: > If a bunch of applications are listening for fork events, > your patch allows any application to turn off the > fork event notification? Is this the right behavior? Yes it is. The main management is done by application so, if several applications are listening for fork events you need to choose which one will turn off the fork connector. I want to keep this turn on/off mechanism simple but if it's needed I can manage the variable "cn_fork_enable" as a counter. Thus the callback could be something like: static void cn_fork_callback(void *data) { int start; struct cn_msg *msg = (struct cn_msg *)data; if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable))) { memcpy(&start, msg->data, sizeof(cn_fork_enable)); if (start) cn_fork_enable++; else cn_fork_enable > 0 ? cn_fork_enable-- : 0; } } What do you think about this implementation? Guillaume - 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/