On Mon, 2005-03-21 at 23:07, Guillaume Thouvenin wrote:
> 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;
> }
> }
I think a better way is:
Providing a different connector channel called the administrator
channel which can be used only by a super-user, and gives you
the ability to switch on or off any connector channel including the
fork-connector channel.
For lack of better term I am using the word 'channel' to mean
something that carries events of particular type through the
connector-infrastructure.
RP
>
>
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
