On Tue, 2005-03-22 at 11:22, Evgeniy Polyakov wrote: > On Tue, 22 Mar 2005 10:26:19 -0800 > Ram <[EMAIL PROTECTED]> wrote: > > > 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. > > Only super-user can bind netlink socket to multicast group.
ok. I did not realize that. > > > For lack of better term I am using the word 'channel' to mean > > something that carries events of particular type through the > > connector-infrastructure. > > I still do not see why it is needed. > Super-user can run ip command and turn network interface off > not waiting while apache or named exits or unbind. > > In theory I can create some kind of userspace registration mechanism, > when userspace application reports it's pid to the connector, > and then it sends data to the specified pids, but does not > allow controlling from userspace. > But I really do not think it is a good idea to permit > non-priviledged userspace processes to know about deep > kernel internals through connector's messages. Yes. non-priviledged userspace processes should not know any deep kernel internals through connector events. I think what I am driving at is, an application that is critically dependent on the fork-notification, suddenly stops receiving such notification because some other application has switched off the service without its notice. the reason I am concerned is I am planning to feed this fork-events to my in-kernel module. Side note: I would really like support for in-kernel listners through connector infrastructure. RP > > > RP > > > > > > > > > > > > > What do you think about this implementation? > > > > > > Guillaume > > > > > > Evgeniy Polyakov > > Only failure makes us experts. -- Theo de Raadt - 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/